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.
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): http://www.rpad.org/Rpad/mapdemo.Rpad Here's another one that generates a viewable list: http://www.rpad.org/Rpad/MoreGuiExamples.Rpad Another advantage is that the R interface to the toolkit doesn't have to know about every single widget and data type in the toolkit. It just needs to know enough to "get the job done". That means the gui interface can grow in capability with time (like the R tcltk system has). Another advantage is that you can build gui's without programming in C or other compiled language (either use R to generate a gui, or use a gui designer). While XUL is the most prominent "sophisticated" toolkit that works this way, others do too. Gtk has an XML-based format used by Glade, and python has been interfaced to gtk via that (PyGtk). I think Qt has something similar. While this approach is best suited for making custom applications, could it also be used for a do-everything ide/gui designer/editor/command line interface to R? It's probably doable but a lot of work (see http://www.activestate.com/Products/Komodo/ for an XUL ide). Whatever path someone tries for a do-everything gui, a good goal is to include dynamic gui generation, so users (albeit advanced) can be gui designers. Where does this path lead? I think the browser will continue to improve as a platform for gui development. Google's gmail is a good example. I've often thought of trying to put together a package for R that was an XUL app that was a stripped-down browser that just displayed Rpad pages (but even that was too much C/C++ programming to get me excited). That would make distributing Rpad pages as stand-alone applications easier. An R package that displayed XUL apps and could make the connections to a gui would also be interesting. - Tom Tom Short EPRI Solutions, Inc. http://www.Rpad.org/Rpad -- Interactive, web-based engineering solutions. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Friedrichsmeier Sent: Thursday, October 20, 2005 7:18 AM To: r-sig-gui@stat.math.ethz.ch Subject: Re: [R-gui] [Rd] R GUI considerations While I totally agree with the general directions of you mail, I don't agree with your points 4 and 5. > 4) What is the language that is working an all platforms R runs, is > perfectly compatible with R, and is always available once R is > installed? Well, R itself (i.e., the S language), of course! So, to > make sure your GUI code is most usable by the R community, write as > much GUI code as you can in S language... and if you think you can > write everything in you XXX language, think again, and you will > realize that a large part of that code can actually be written directly in R as well. > > 5) There are new and better graphical widgets and languages appearing > regularly in the computer world. The best ones for making a GUI today > may be obsolete rapidly in the future. On the contrary, we all hope a > longer life for R. Thus, write your GUI code in R as much as possible > in a way it is independent from a particular GUI toolkit and > interfacing language. I say, as much as possible, because this is a > very diffcult task, given the specificities of each toolkit and language. _______________________________________________ R-SIG-GUI mailing list R-SIG-GUI@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-gui
