My two cents is that Tinn-R is a great, small program to use as an IDE and
that Rpad is a simple way to quickly make R functions available to
non-programmers. What I like about Rpad is that it can be accessed from a
web page so the user doesn't even have to have R installed on his machine. I
am just not convinced that we need a large all-inclusive menu driven GUI
that will sit on top of R and hog a lot of resources. Insightful already
provides that. I love to see improvements in R, but it seems that the path
down GUI developement could be a never-ending road.

On 10/21/05, Short, Tom <TShort@eprisolutions.com> wrote:
>
>
> 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@stat.math.ethz.ch
> [mailto:r-sig-gui-bounces@stat.math.ethz.ch] 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
>

	[[alternative HTML version deleted]]

