On Mon, 25 Nov 2002 21:09:40 +0100 (MET), you wrote in message
<permail-200211252009404294-friedtcb@ruhr-uni-bochum.de>:
I think we should start at a lower level (a widget that gives a list
of strings to select from), and then implement a list of available
objects as a string list widget that has been populated by the names
of available objects.
Well, this may be going a bit into details already, but do we really need this? Do you ever need to select strings from a list, that do not represent R-objects?
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. 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.
We also need buttons, and the ability to attach actions to user
actions. (E.g. click on a button or change the entry in a widget and
execute some R code).
Do we? Of course the GUI-itself does need some buttons e.g. for executing R-code, but there should be no need to explicitely define those. They should simply be generated by the application, not stated in the "plugin".
I don't know what you mean by this. I think you're right, that we're
talking about different things.
I still believe, we're partially talking about different things. Whether the application wants to show a help-menu on a right-click somewhere or on a hover, whether something gets pasted into a field or typed manually etc. should entirely be the responsibility of the application, not be defined inside an XML-file to be shared across projects. That's what I mean when talking about "high" level - the XML-specification should really say nothing about what happens when you right-click on some button. It should allow you to state: "Ok, I need this standard-R-widget here that represents a numeric value. If it happens to provide the functionality for a context-help (by whichever means), display the text specified. If it happens to support a header-label, display that other text here. I don't care what it looks like, and I don't care, whether the value is read from a silly slider or some more serious control. Just put it there."
I agree with the second part, but I think we also want to allow the
GUI to generate events.
We should also have a tree view widget, and a free text entry widget.
It probably makes sense to have a widget for entering longer texts, but do we really need a separate tree-view? What else would you want to put in there, if not the available variables?
"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.
I'm not sure why this needs to generate R code. Why not just have a
function to retrieve the values of all widgets that have values?
Umm, yes, exactly that. And that function would result in some R-code. Or are we talking about something different here?
Let me post again the section in my example:
<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.
Duncan