[R-gui] Another R-GUI

[Thomas Friedrichsmeier]

Please note, that the questions I ask are really meant as questions, and are not purely rhetorical.

> I think there should be finer granularity than that.  We shouldn't use
> Delphi's scheme of counting things in pixels (Delphi has problems when
> you change fonts, or change screen resolutions), but some sort of
> device independent coordinates (e.g. the dialog coordinates run from 0
> to 1 in each direction) would be better than assuming it's a grid.

I think assuming it's in a grid is not all that bad as a start. After all, if the widgets do look different in different projects, it's dangerous to specify even relative sizes. I admit, that the idea of rows and columns is somewhat inspired by Qt, which uses rows and columns for layouting, but I guess something like this is available in other toolkits, too?
Anyway, we might of course add some percentual width-attributes (kind of like it's done in HMTL-tables), which could be taken as a hint to the layouting-engine, thereby adding a little more flexibility.

> >- some sort of widget that lists available objects (the "varselector" in my
> >example)

> 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? Of course, if we really need this, that should not be much of a problem, and RKWard's implementation of a "varselector" acutally works much like that internally.

> >- a widget that can hold a (single) object (the "varslot"), and will
> probably
> >make some specifications about what types of objects it can hold (like the
> >attribute type="numeric" in the example)
> >- maybe a separate widget that can hold one or more objects, but basically
> >acts the same (might instead simply use a more generalized "varslot")
> >- maybe a separate widget that can hold a single constant value (number or
> >string)
> >- a widget that can be used to select interactions between variables
> selected
> >in a "varslot"

> In the same way, we want the lower level components that make these up
> to be available.

Do we?

> >- radio-buttons
> >- checkboxes

> These are low level.

Ok, admitted.

> >- a widget representing a text/label not directly attached to any of the
> other
> >widgets

> No need to make this special now, it's just a low level label...

True, but I was actually trying to give a _complete_ list, i.e. this is all the widgets, I think we need (at least for a first draft).

> >- a widget represent a line or other separation used for layouting purposes

> We often want boxes, so it might make sense for that to be the lowest
> level, with one style being a box with only one side visible.

Sounds reasonable.

> 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'm not sure how many of these we want, but
> there could be a lot.  For example, Delphi allows 16 different kinds
> of events to be triggered by a button:  clicks, mouse
> move/push/release, context sensitive help popup, 3 for drag and drop
> functions, 2 for "docking" functions, 2 for focus entering/leaving the
> button, and 3 for key presses while the button is focussed.  Since we
> don't want all of these from the beginning, but we might want some of
> them later, I think we should make it easy to add additional events to
> components.

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."

> 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?

> 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>

Here my "code-generation" is to simply replace everything inside $$ with the values in the GUI (I have two "varslots" with tagged "x" and "y", and a group of radio-buttons tagged "hypothesis").
I'm simply not sure, whether a simple search-and-replace like this is flexible enough.

PS: No need to CC me, I'm on the list (with a different mail-account)