[R-gui] [Rd] R GUI considerations

[Short, Tom]

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: r-sig-gui-bounces at stat.math.ethz.ch
[mailto:r-sig-gui-bounces at stat.math.ethz.ch] On Behalf Of Thomas
Friedrichsmeier
Sent: Thursday, October 20, 2005 7:18 AM
To: r-sig-gui at 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.