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