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) .......................................................................
[R-gui] XML specifs for R GUIs dialog boxes
1 message · Philippe GROSJEAN