Re: [Rd] [R-gui] R GUI considerations

From: Philippe Grosjean <phgrosjean_at_sciviews.org>
Date: Sun 16 Oct 2005 - 12:32:25 GMT

Hello James, Duncan and the others,

There are interesting arguments in your posts. I think I must react to one of Duncan's considerations:

"Philippe, while you think that people are to individualistic in their development of GUIs, I think perhaps a better interpretation is that many of us are trying to develop GUIs quite different from what you have in mind. Your mail talks as if there is a single, yet-to-be created GUI. There is no single concept of a GUI and we have been over this many times to little avail."

We probably have the same feeling about the large palette of possible GUIs (look at the page http://www.sciviews.org/_rgui/rgui/GUIs.html, that I wrote more than one year ago). However, my idea is effectively to make a single GUI, flexible enough to accomodate all situations and uses (do I need to add that it is *not* necessarily derived from SciViews, but it must certainly arise from a collaborative work between all people interested in the R-SIG-GUI list and others).

There are several functions shared by the various R GUIs, and recoding the same function again and again is really a waste of time. If you carefully look at JGR, SciViews-R and R Commander, you will see that the same main paradigm is used: a script editor in top of bottom of a console window, plus "helpers" to ease beginner's work (menus & dialog boxes, object explorer, etc... Again, not the only possible GUI, but one that proves useful in some situations). For instance, the object explorer has been coded at least three times (once in JGR, once in SciViews-R, and again, a more static and basic one in R -browseEnv() in utils package-). What a waste of time that would have been avoided if there was an "R Object Explorer API" available that everybody can reuse. This is where I see too much individualism: nobody, including myself, considered that the functions they wrote for the object explorer should be done and documented in a way they would be reusable by others (exception of browseEnv(), of course). I could cite countless examples here.

Where I am more surprised, it is when I proposed that idea of a reusable R GUI API one year ago, and started to write it, I found no echo at all in other developers. Nobody seems to be interested by the idea of reusable building blocks for R GUIs, although reusability is really the key of successful software development nowodays. Duncan, I am pretty sure you feel that all you did in OmegaHat is underused, probably for the same reason.

Other reasons why a good and fully-featured R GUI takes very long to develop in an Open Source context: the lack of programmers. Good R programmers, those who actually make R, are more interested by enhancing R itself than by writting a GUI for it, because they don't need a GUI and are pretty satisfied with the CLI and/or ESS. Other kinds of programmers wanting to participate in the development of Open Source software are more encline to participate to widely used software like Apache, Mozilla, OpenOffice, etc... than to dedicate their free time for programming a GUI for an obscure statistical software, with marginal use compared to the previously cited software. Finally, the only programmers really interested by a R GUI have very specific needs, like the use of R for teaching (John Fox, and myself, for instance)... and it happens that the very few people ready to dedicate a part of their free time to the development of a R GUI all act as individualists, starting their own project alone and with no or little reusability between GUIs projects in mind.

In such a context, the situation is pretty desperate. Open Source means software made by users for users... but in the particular case of R GUIs, users that need them (beginners), usually are those that *cannot* participate to their development, and the Open Source paradigm simply does not work as well for that particular reason.

That said, we are intelligent and proactive people. So, once the situation is analyzed, could we react in a positive way? Could we decide to put each piece of experience, materialized by several half-finished R GUIs (the current R GUIs that are considered as finished are indeed less ambitious projects, satisfied with a couple of basic features, which is the same result as more ambitious projects flagged as half-finished).

Some thinkings in this direction lead me to build a bridge between R Commander and SciViews-R, and in a near future, between Rpad and SciViews-R. Also, with Jose Claudio Faria, we are thinking on a reimplementation of Tinn-R in a platform-independent way, probably Java-based... a possible bridge with JGR is obvious here. These thinkings are summarized in a document: http://www.sciviews.org/EclipseAndR_Evaluation.pdf. Also, for what I tell about the idea of a R GUI API, one could read part II of the SciViews-R manual (http://www.sciviews.org/SciViews-R/Manual.pdf).

I am not much interested by endless discussions and considerations. I would rather like to feel a serious willingness in starting a collaborative work between all people that will read this email... and I am waiting for real actions going in this direction. As I said, I will have a couple of contracts in 2006-2007 where the development of a R GUI is part of the job, leaving me the opportunity to hire one or two developers on it. Whether these developers will continue the work on the current Windows-only SciViews-R, or on a more general project will largely depend on the echo I got in the R GUI developers sphere, regarding my suggestion of a reusable R GUI API and a polymorphic and full features R GUI as sketched in the two document cited hereabove. Best regards,

Philippe Grosjean

James Wettenhall wrote:
> Hi Philippe and everyone else,
>
> As you know, I have certainly spent some time thinking about R-GUIs, and
> developing some R-Tcl/Tk GUIs - limmaGUI and affylmGUI (available from
> Bioconductor). I have also spent some time wishing we could use a GUI
> toolkit with a more modern look and feel. Hence I have investigated
> wxWidgets, and thought that using wxPython might be the easiest way to
> interface it from R, but I ran into some technical problems (especially
> because I was obsessed with trying to make the interface from R to wx seem
> not-too-object-oriented, i.e. I like the idea of 1. create a dialog, 2.
> add a button etc. like in Tcl/Tk rather defining a dialog class, then
> defining an object which is an instance of that class and then invoking a
> show method on that object etc.)
>
> I can't really afford to make R-GUIs much of a priority in my work any
> more (so I may not read these philosophical discussions about which GUI
> toolkit is best as closely as I used to), but I'm happy to answer any
> specific questions about my experience with R-GUI development. I hope
> that doesn't sound too presumptuous of me, but I think that John Fox's
> R-Tcl/Tk GUI package (Rcmdr) and mine (limmaGUI and affylmGUI) are some of
> the most sophisticated (and most popular in terms of users) attempts to
> build a platform-independent GUI interface to a command-line R package (or
> packages). And then there are other really nice GUIs for R which are not
> necessarily platform independent - like some of Philippe's SciViews
> software, and I recently came across a really nice GUI using GraphApp
> (Windows only) for connecting to ODBC - I think it was in Brian Ripley's
> RODBC package.
>
> One point I wanted to make here is that there are some people in the R
> community who have really great experience to offer from trying to develop
> better R GUIs, but who don't necessarily participate on the R-SIG-GUI
> mailing list. For example, I was talking to Jan de Leeuw on the R-SIG-MAC
> mailing list and he mentioned that he has done some great work trying to
> interface R-wxPython, but that it was difficult maintaining the glue
> between the different components. And there are people in Bioconductor
> (e.g. Jianhua Zhang - widgetTools & tkWidgets, Jeff Gentry -
> widgetInvoke) and there are people who have been involved in OmegaHat e.g.
> Duncan Temple Lang who all have great experience to offer.
>
> But some of the 'philosophical' ideas that people would like to implement
> e.g. interfacing R and wxWidgets 'directly' without going through Python
> (e.g. using Cable Swig) (or interfacing R and Tk via C rather than via
> Tcl) seem like a massive task, and no-one seems sufficiently motivated to
> provide money to employ someone (or multiple people) to do something as
> big as that.
>
> Just my thoughts. Feel free to ignore.
> Regards,
> James
>
> ______________________________________________
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>

Duncan Temple Lang wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I think it is a little premature to entirely discount Gtk2, especially if it is based on Philippe's remark below. Philippe, did you try other applications, different themes, different configurations, or just the vanilla GIMP? and when? While I don't necessarily disagree with the claim that it is different from Windows look and feel, it requires a little bit more evidence.

When I complete the SWIG module for R and the associated more advanced tools, I may pursue an automatically created interface to wxWidgets that would by-pass the RSPython dependency.

Unfortunately, many people have become more vested in Tcl and sub-optimal solutions because it is there. We need to keep pushing infrastructural development and what is feasible. For some of us, the collection of widgets and the possibilities that they introduce are more important than cosmetic details, which of course are important but won't necessarily advance the paradigms of analysis.

Philippe, while you think that people are to individualistic in their development of GUIs, I think perhaps a better interpretation is that many of us are trying to develop GUIs quite different from what you have in mind. Your mail talks as if there is a single, yet-to-be created GUI. There is no single concept of a GUI and we have been over this many times to little avail. But many of us think that a generic GUI is of little research or even practical value. But we do think customized interfaces, e.g. to interactive, dynamic documents, is worthwhile. Hence the differences. And hence also the development of truly extensible toolkits, rather than specific views of what a GUI would like. It is great that you want to focus on a particular group of potential users; likewise for JGR, Rcmdr, etc.

Also, while R is a functional language which Duncan Murdoch has mentioned in another mail and so is different from other languages such as C/C++, Python, etc. that have been used to develop GUIs, the ability to have mutable state via closures has not inhibited us in developing GUIs in R. And the event loop is not intrinsically different in these other languages (except Java). It is just something that some of us have to agree on.

Enough for now.

  D.



R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel Received on Sun Oct 16 22:40:28 2005

This archive was generated by hypermail 2.1.8 : Mon 24 Oct 2005 - 22:28:16 GMT