[R-gui] [Rd] R GUI considerations

[Thomas Friedrichsmeier]

> I think there's a useful middle path between the do-it-in-R side
> and the do-as-little-as-possible-in-R side. For this middle path,
> the key is a "gui engine" that can dynamically create a gui. You
> can think of a web browser as a gui engine -- it receives gui
> instructions from a server and displays them for interaction with
> the user. The gui instructions are html (and maybe
> javascript). XUL and Firefox/Thunderbird works in a similar
> fashion. Much of the gui is specified in a gui language (XUL). A
> key feature of this is that the gui is separated from the program
> logic. For R, the gui engine would provide the event loop and
> communicate with R as needed. The existing R tcltk interface
> works that way -- you can program parts of the gui interface on
> either side (R or tcl), depending on the needs of the
> program. With tcltk, the "gui language" is tcl, whereas with
> Mozilla, the gui language is XUL.

To a large degree this is much like what I'm using in RKWard. "Plugins" are 
defined in an XML format, that allows you create specialized GUI elements 
(like "a widget to select a variable") with a single tag. This XML format is 
interpreted by C++-code to actually create a GUI, but there's no 
C++-programming involved in defining the plugin, and it would be possible to 
write interpreters in different languages, for different toolkits.
The main difference here is, that I do not see R as a "server" requesting GUI 
actions at all, but rather use it almost entirely as a "backend" doing 
calculations.

> Rpad works in a similar fashion. It uses a browser to display a
> rudimentary user interface. You can develop the interface by
> hand-writing html, using an html editor, using the builtin
> editing capability, or having R generate gui elements (with help
> from R2HTML). Having R be able to generate gui elements is quite
> useful in a number of situations. See here for an Rpad example of
> a dynamic graphic (a clickable map that generates plots on each
> click):

In fact, doing dynamic graphs is one things, where you need R to become more 
active. However, I think the vast majority of functionality will not need 
such a kind of interaction (that, of course depends, on what the main purpose 
of the GUI is), and for those portions I try to keep R out of the way. One 
advantage of having large portions of the GUI independent of R (at least the 
creation of the GUI/interaction with the user), has the advantage, that the 
GUI not only remains responsive while R is doing a lengthy calculation, but 
you can actually work with it while R is busy.

Certainly, a do-it-all GUI will have to use some sort of a middle path. But 
whereever possible I try to err on the side of doing GUI work outside of R.

Well, anyway, that's just my philosophy, and as mentioned, I don't think it's 
the only possible approach. I think indeed, we should have a common wiki for 
R GUI projects, as suggested by Philippe. Among other (and possibly more 
important things), it might contain a section comparing (but not judging) the 
various approaches/designs used in the various projects in more detail. 
Ideally, this might make it easier for projects to recognize who else is 
actually working in a similar manner, and with whom you could easily share 
some technologies.

Regards
Thomas Friedrichsmeier