[R-gui] Another R-GUI

[Philippe Grosjean]

I think at this point, we should not try to reinvent the wheel: the
mechanism used in Splus (although there are some part of the dialog boxes
implementation in Splus that I hate), and even better, in Matlab are good
example of powerful dialog boxes building. There is the possibility to
define a CallBack function for each user interaction with the dialog box.
Thus, the treatment is then passed to the calculation engine, and is done
natively (no need to duplicate a parser, if-then-else, and the like). In
Matlab, there is a possibility to build such an interactive graph with
control button that Duncan envisions.

However, as powerful is this callback mechanism, in my experience, it is not
easy to figure out how to construct even the simplest dialog box this way. I
am now used to do it, but not all my collaborators understand this approach
yet! Consequently, I am not opposed to an alternative way of managing the
dialog box that could be easier, like the simple replacement mechanism
proposed by Thomas. I believe that both should be available simultaneously
(one for simplicity, the other one for power).

Considering the layering mechanism, I think a similar approach should be
favoured:
- a simple, almost automatic layering mechanism based on a grid for quick
and easy building of simple dialog boxes,
- and a finer mechanism for more complex layering requirements.

Lukily enough, it seems both of you (Thomas and Duncan) are complementary in
this approach. So, let's use a AND, instead of a OR, here ;-)

Thomas

-----Message d'origine-----
De : r-sig-gui-admin@stat.math.ethz.ch
[mailto:r-sig-gui-admin@stat.math.ethz.ch]De la part de Thomas
Friedrichsmeier
Envoye : lundi 25 novembre 2002 22:42
A : r-sig-gui@stat.math.ethz.ch
Objet : Re: [R-gui] Another R-GUI


> The example I'm thinking of is a dialog box at the side of a graph,
> where you can make changes to the way the graph is generated.

I admit, I had not spent too much thinking on interactive graphs, yet. That
does indeed change some things.

> For
> example, if you want to plot densities, you might have a set of
> radiobuttons to choose which distribution, or you might prefer to have
> a string list of their names.  The radiobuttons work well when there
> are a small number of choices, the string list works better when
> there's a long list.

Ok, that makes sense.

> I agree with the second part, but I think we also want to allow the
> GUI to generate events.

I can now see, that for the above example, this makes a lot of sense. I'd
want to keep thing as simple as possible though, and allow only a limited
set of events. One such event might be something like a "submit", i.e. make
R e.g. redraw the graph whenever you switch a certain option. What else
would we need?

> "Lists" in R are really trees.  It would be nice to be able to look at
> them that way, expanding and collapsing the various branches.

Ok, but, but wouldn't it be good enough, if the "varselector" could simply
display them that way? Do we need it in any other context (except from
simply browsing objects, which IMHO would not need to be realized as a
plugin)?

> ><code>
> >   t.test ($x$, $y$, "$hypothesis$")
> ></code>

> The way I was thinking about things is that we'd have a high level
> parser that would translate what you wrote above into some detailed
> GUI representation (probably a dialog box with 3 labels beside 3 text
> entry fields).  But there should be other ways to generate the GUI
> components.

This time, we're not only talking about different things, but I can also
explain in which respect ;-). The section I quoted is just a small part of
the example XML-file. It is NOT about describing the layout or even about
specifying what types of GUI-components there should be. There is another
section (<layout></layout>) which defines which ("high-level") widgets
should be placed where, what kind of values (e.g. numeric) they require, how
they are labeled, whether it is mandatory to fill them... See the whole
thing in the r-sig-gui-archives somewhere around two weeks ago.
The <code/>-section is only about, how R-code is to be "generated" from the
selections made, and in this case means: Take the values of the widgets "x",
"y", and "hypothesis" (two varslots and one radiobutton-group in this case)
and insert them into a string as shown.
The resulting string is what gets sent to R, when the user presses (in my
case) "Submit" (and also the (partially) completed command is shown while
the user is making selections, so you can watch the command being put
together).
So again, do you think, a simple search-and-replace will be good enough for
most purposes, and if not, what should we go for?

Thomas

_______________________________________________
R-SIG-GUI mailing list
R-SIG-GUI@stat.math.ethz.ch
http://www.stat.math.ethz.ch/mailman/listinfo/r-sig-gui