[R-gui] Another R-GUI

[Duncan Murdoch]

On Mon, 25 Nov 2002 18:13:16 +0100, you wrote:
>I think we're pretty much on a good way concerning the specification of what a 
>dialog should look like (we probably don't need more layouting-functionality 
>than rows and columns and potentially tabs),

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.

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

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

>- radio-buttons
>- checkboxes

These are low level.

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

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

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

We should also have a tree view widget, and a free text entry widget.


>Another thing, that might however deserve some further consideration, is, how 
>the selections made in a dialog created this way, should be transformed into 
>R-code. The example I sent, simply uses a search-and-replace mechanism, that 
>works surprisingly well, but might be too inflexible. This means, that we 
>might have to agree on either some "if" and "else" tags in our XML, or on 
>some sort of scripting language like e.g. PHP, that will be used to generate 
>the code.

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?

Duncan Murdoch