[R-gui] [Rd] R GUI considerations
phgrosjean at sciviews.org
Sun Oct 16 14:32:25 CEST 2005
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
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.
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
> 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.
> R-devel at r-project.org mailing list
Duncan Temple Lang wrote:
-----BEGIN PGP SIGNED MESSAGE-----
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
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
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.
More information about the R-SIG-GUI