Since this becomes a fairly large thread that goes in many different (and interesting) directions, I propose to start a new one with a more explicit title. I will try to summarize major points discussed so far. - Thomas Friedrichsmeier [Thomas.Friedrichsmeier@ruhr-uni-bochum.de] after "having a short conversation with the obveRsive-people" introduced the idea of a sort of "plugin" with potentials to contruct dialog boxes at run- time. He proposes to use a XML-file for specification of the dialog box (ex: t-test dialog box, http://rkward.sf.net/pics.php). - We all agree (I think) that a common semantic for the description of these dialog boxes accross projects (whatever the language, the graphical toolkit and the platform used) should be fine. So, we are on the way to define it, and I'll dedicate a page to it at http://www.r-project.org/GUI, as soon as we have something consistent (thus, discussed enough in R-SIG-GUI). Also, this implies it should not be describing features at a too low level, as pointed out by Thomas, or we take the risk to get something that would be less portable from one language/graph toolkit to the other. - Peter Dalgaard [p.dalgaard@biostat.ku.dk] suggests to contact people in Bioconductor that may be working on a similar thing (I send them a copy of this mail). - Philippe Grosjean [phgrosjean@sciviews.org] proposes to include context-sensitive features, allowing for instance to call such dialog boxes directly from an object explorer, or whatever context menu. - While Philippe and Thomas think that a majority (but not all) dialog boxes could be constructed this way (they probably bear in mind a way to quickly construct simple to rather complex dialog boxes, but not an exhaustive approach), Duncan Murdoch [murdoch@stats.uwo.ca] considers that it should be possible to make it more exhaustive ("I don't see any problem with thinking about all of them as being made of XML"). - Although the specifications could target a run-time dynamic construction of the dialog box, it could also be used to define dialog boxes at design time, at least if we follows the Delphi scheme, as pointed out by Duncan (?). A.J. Rossini [rossini@blindglobe.net] says that it is "just a matter of translation, for the most part". Probably, this should be more a question of implementation in the various different languages and should not be discussed too deeply in the early stages. - About layering, Thomas proposes something simple, like a grid with perhaps tabbed dialog boxes (note: this is roughly the layering potentials of Splus custom dialog boxes), while Duncan whould like to have something more powerful. - The list of widgets to support is not fixed yet too. Duncan proposes to focus on low level widgets first (label, text, button, etc...). Thomas proposes a list that mixes low level and high level widgets (I think we should make the distinction and propose two separate lists). At this point, we should also discuss with the Bioconductor team that has already done some work on creating various interesting high level widgets in tcltk like objects lists for instance. Here is the widgets list propsed by Thomas: "+ some sort of widget that lists 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" + 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" Duncan adds: + a tree view widget + a free text widget I'll immediately add: + various classical dialog boxes like file open/close for instance + a widget that displays a (multi)-selectable list of columns in a particular data frame, or elements in a list. + a graph widget (yes a whole R graph device) And perhaps: + a menuing system (with perhaps context menus attached to other widgets) + sliders to select values in a range - There are some open aspects, like the possibility to define new widgets, or the way results are submitted to R (simple seach/replace mechanism, data frame or other code describing the whole dialog box and processed by R code,...). - Since someone must initiate a document for the specifs, and Thomas seems to have something almost ready, I proposed him to make a draft. At this stage, modifications in a document will be more constructive than loosy discussions in R-SIG-GUI. Best, Philippe P.S.: for those of you that receive this mail and are interested, but not listed yet on R-SIG-GUI, you can register at: http://www.stat.math.ethz.ch/mailman/listinfo/r-sig-gui Special Interest Group on Development of GUI(s) for R. Topic: Discussion of Strategies and approaches; particularly platform independent ones. See http://www.R-project.org/GUI/ for more. ...........]<(({?<...............<.............................. . ( ( ( ( ( ) ) ) ) ) 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) ...................................................................... .