[R-gui] XML specifs for R GUIs dialog boxes

[Philippe Grosjean]

Some clarifications about what we do here:
------------------------------------------
We are specifying the definition of a plugin-description language for
R-frontends. This language, probably in XML, aims to define simple and
highly portable dialog boxes for R graphical user interfaces. Highly
portable means that it should be as much abstracted as possible, and in
particular, remain independent for a particular graphical toolkit, a
particular programmation language and a particular plateform. These files
aim to be parsed and translated in actual dialog boxes in the various R GUI
projects in a similar (or at least "compatible") way, while leaving the
freedom to adapts various aspects to obtain a GUI that is homogeneous with
the look & feel and some other particularities of each environment
(environment, here, is taken as a combination of a programmation language, a
graphical toolkit, a R GUI project, and possible also a plateform).


==== WHY? ====================
Very early (the discussion stated in R-Help, befor R-SIG-GUI was born),
there is a long thread about which graphical toolkit should be used for R
GUI. This discussion never ended with a winner. As a consequence, we should
expect the developement of different GUIs using different graphical
toolkits. In this context, how to append graphical elements (mainly menus
and dialog boxes) to R packages, while remaining compatible with the
differents projects? Answer, by using a higher level definition language of
these dialog boxes that makes abstraction of the particularities in each
project, as much as possible.

[If, in your own opinion, this is totally silly, or impossible to do for
technical reasons, then please, share your knowledge. Otherwise, we proceed
further.]


==== WHAT WE DO ==============
We define a specification language using XML tags. It describes what the
dialog box should contains (various graphical features, or "widgets"), and
how it should react to user actions (mainly submit R code modified according
to the context of the dialog box (variable replacement mainly) when the "OK"
button is clicked, but also interactions between the dialog boxe and
R -events-), as well as how to invoke help.

Such a file is intended to be parsed and translated by an engine (that I
will call here, a "translator") in an actual form specification/code for
building the dialog box using a particular programming language combined
with a particular graphical toolkit (Tcl/Tk, Gtk, Swing, ActiveX/OCX,...),
and possibly specialized widgets like those currently developed for tcltk by
the Bioconductor group.

This file should be very easy to build for simplest dialog boxes. Anybody
should be able to write one, and to translate it in dialog boxes, at least,
using the most automatted "translators" (this will be obviously dependent
upon the level of automatisation provided by each translator). Of course,
more complex dialog boxes, will obviously require more work.

The ultimate level in simplicity would be to pick up any R function and to
create a specification file just by filling a dialog box asking how each
function argument should be translated into a graphical widget (text, list,
pushbuttons,...).


==== WHAT WE DO NOT ===========
Specification will not fit _all kinds_ of dialog boxes or GUI elements (most
complex ones, or those using very specific features of such or such
graphical toolkit or language will no be descriptible by this language). We
favor simplicity rather than exhaustivity!

Specification do not define the code used to interact with the dialog box.
Basically, an event calls a R function that does the job (or perhaps, if the
action is simple enough or best handle in another way, a scripting
language -Thomas proposes PHP, I must admit I would personnally prefer to
use JavaScript, other could argue for Perl or Python, or ... probably-). For
the simplest dialog boxes, it will also propose a variable replacement
system in R code that is then submitted to R.


==== HOW DO WE DO THAT? =======
We will produce a draft of a specification document, supported by a little
brainstorming in R-SIG-GUI. This draft will be posted in
http://www.r-project.org/GUI. Thomas wrote a skeleton that I formatted. As
soon as we agree on its presentation, we will share it and allow everybody
to append comments on it. The draft will be a compilation of all these
comments.

The critical stage will be to test it. At this point, we will need to write
the core of translators in various contexts (at least tcltk for it is
largely integrated to R in most plateform, I suppose Thomas is writting
something similar for Qt in its RKward project, I could probably write
something using OCXes under Windows in the framework of SciViews,...).

Flaws and lacks will be reveiled when testing translators. This will lead to
a modified document for the specifications. At that time, we will submit our
proposal to the whole R community.


==== MISC =====================
The sensitive question: should we design our own specifications, or should
we reuse existing standards (HTML, XForms, Jelly where proposed)?

The Bioconductor team seems to do something similar, but using lists in R
language?

To proceed in the right direction, we all need to identify clearly the same,
unique goal.

Philippe

...........]<(({°<...............<°}))><...............................
( ( ( ( (
 ) ) ) ) )      Philippe Grosjean
( ( ( ( (
 ) ) ) ) )      IFREMER Nantes - DEL/AO
( ( ( ( (       rue de l'Ile d'Yeu, BP 21105, 44311 Nantes Cedex 3
 ) ) ) ) )      tel: (33) 02.40.37.42.29, fax: (33) 02.40.37.42.41
( ( ( ( ( 
 ) ) ) ) )      SciViews project coordinator (http://www.sciviews.org)
( ( ( ( (       e-mail: phgrosjean@sciviews.org
 ) ) ) ) ) 
( ( ( ( (       "I'm 100% confident that p is between 0 and 1"
 ) ) ) ) )                                L. Gonick & W. Smith (1993)
.......................................................................