[R-gui] [Rd] R GUI considerations

[Philippe Grosjean]

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 at 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.