[R-gui] Another R-GUI

[Duncan Murdoch]

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