[R-gui] Another R-GUI

[thomas]

On Monday 25 November 2002 16:31, Philippe Grosjean wrote:
> I must probably explain a little bit, because when I talk about "complex
> dialog boxes", it is not very clear what I mean. Nobody will contradict me
> when I say that the dynamic dialog boxes, as described in a XML file should
> be as portable as possible. In particular, it should be possible to create
> similar dialog boxes using different graphical toolkits, from the same XML
> specification file (Visual Basic/Delphi/VC++ for SciViews; Swing for
> ObveRsive; Qt for RKward; Tcl/Tk or GTK for other projects). However, this
> would limit the building blocks -the widgets- to a core basic set that is
> common to all toolkits. There will certainly be some cases where the
> programmer would like to use specific widgets, or exotic features. For
> instance, I have some ideas on how to implement dynamically a dialog box
> composed of standard widgets in Visual Basic, but it is not obvious to me
> how I could dynamically add some exotic OCXes at run time!

I'm not sure, whether we're not already thinking along the same lines, anyway, 
but to clarify: The XML-specification I'm talking about should IMHO use some 
rather high level "widgets", which simply make sense for an R-frontend, and 
not orient itself at the widgets available in a certain toolkit.
E.g. the "varslot"-widget in the example I posted, is something that will 
likely occur at many places in many different R-frontends, but likely is not 
a widget contained in any toolkit. Rather all frontends, that would like to 
use the "plugin" would have to implement some way to construct something that 
can act as a "varslot". Internally in RKWard, this is acutally composed of 
three Qt-widgets (a button, a label and a lineedit), in another project it 
might look different, as long as it provides the same core functionality.
Moreover, projects should be free to offer extended functionality for the 
"varslot", such as applying some transformations on the selected object - 
this would not be described in the XML-file, however. The definition for that 
dialog still remain the same and be useful across different projects, that 
offer different functionality.
This means, that not every nifty feature we plan to implement in our projects 
might be possible to describe this way, but for lots of "simple standard" 
stuff like analyses of variance, correlations... it shouldn't be a problem. 
For other features, we would have to create custom solutions that can not 
easily be shared across projects.

> Consequently, I
> suppose that a few percentage of the dialog boxes will not be portable and
> will probably not benefit the dynamic implementation (they will be much
> easier to build at design time and be embedded in a shared library, for
> instance).

Agreed.

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), and I guess we should be able to 
agree fairly quickly on a set of "widgets" we need. The ones that come to my 
mind are:

- some sort of widget that lists available objects (the "varselector" in my 
example)
- 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"
- radio-buttons
- checkboxes
- a widget representing a text/label not directly attached to any of the other 
widgets
- a widget represent a line or other separation used for layouting purposes

Did I forget anything important? Anyway, the list is probably not all that 
long, which also means, that implementing a parser and GUI-builder for this 
XML will not be too hard to do.

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.

> Anyway, I will submit the draft to all interested people in time.

I'm very interested.

Thomas