> 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 _______________________________________________ R-SIG-GUI mailing list R-SIG-GUI@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-gui
