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 <[EMAIL PROTECTED]> 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: [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 > [[alternative HTML version deleted]] _______________________________________________ R-SIG-GUI mailing list R-SIG-GUI@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-gui
