[R-gui] R GUI considerations (was: R, Wine, and multi-threadedness)

Hi All,

While I don't have the "sweat equity" that either Philippe Grosjean  
and James Wettenhall have in developing R GUI's, I have been involved  
in two different projects (obveRsive as part of the founding  
development team, and R Commander as a contributor) over the past  
three years. In addition, my interest is in R GUIs that are not  
platform specific (such as Philippe's SciViews for Windows or Thomas  
Friedrichsmeier's RKward for KDE). Based on a combination of both my  
experience and my interest, I want to make two observations, and  
offer three opinions about issues people should consider when  
thinking about what they can do to move GUI's for R forward.

My first observation is that gluing R to any external, platform  
independent, widget tool kit is hard. James indicates that it isn't  
easy for wxWidgets. My memory is he got it to work under Window's,  
but had a hard time making it work under Linux, and Jan de Leeuw also  
found it to be a real challenge just to get the RSPython layer to  
work under Mac OS X. On the obveRsive project we decided to use the  
Fox tool kit because (1) it had a larger selection of more "modern"  
widgets compared to Tk, and (2) it was the only multi-platform  
toolkit that actually worked under Windows, Linux, and Mac OS X  
platforms at the time we started the project in late 2002 (at that  
time wxWindows hadn't actually been ported to OS X). In order to use  
the Fox toolkit, we decided to use R as a backend. However, we, along  
with a number of other failed early projects (we pretty much decided  
to admit the demise of obveRsive this past week), found this to be a  
Herculean task (Zed Shaw in his work on obveRsive spent many  
frustrating nights trying to think of ways to develop a backend  
approach that worked quickly and consistently). Ultimately, R does  
not behave the way Perl, Python, Ruby, and Tcl/Tk do, which makes  
gluing it to an external GUI toolkit a real chore.

The second observation is that the R Tcl/Tk package is incredibly  
robust (the efforts of Peter Dalgaard and others who have worked on  
this effort should really be applauded in my opinion). I've used  
Rcmdr (based on the R Tcl/Tk package) successfully in classes where  
students used a mix of Windows and Mac OS X machines. To be honest,  
that it works at all, let alone that it is so rock solid, under Mac  
OS X simply amazes me since the Tcl/TK widgets use a different  
windowing system (X11) than the R console application (run under  
Aqua) in a standard, CRAN based, setup on OS X.

My first opinion is that too much bandwidth on the R-sig-gui mailing  
list has been spent on philosophical arguments about which toolkit is  
the "right" one to use. From a practical perspective, the Tk toolkit  
works well on all major platforms. The only real potential  
alternative for multi-platform application seems to be Java (as  
Philippe indicates, GTK2 is problematic under Windows, but also has  
some issues under OS X). However, only the JGR project appears to be  
using Java for an ambitious multi-platform application. At this  
point, I would really like to hear Markus Helbig's, Simon Urbanek's,  
Martin Theus's, and other JGR developers' opinions about the  
suitability of Java as a general tool for developing GUI's for R  
since they would have well informed opinions on this topic.

Second, it is my belief that there is a huge potential benefit to  
devoting efforts to simplify the use of the available working tool  
kits (i.e., the R Tcl/Tk package and Java) so that it is easier to  
develop GUI dialogs for a package or a specific procedure. To that  
end, John Fox has developed a number of macro-based "helper  
functions" for Rcmdr that greatly simplifies the creation of GUI  
dialogs for this package. My guess is that some of these could be  
fairly easily included as part of the R Tcl/Tk package. Moreover,  
other helper functions, based on John's approach, could also be  
developed. Going a bit further, as part of the obveRsive project,  
Thomas Friedrichsmeier wrote a module that enabled obveRsive dialog  
writers to write their dialogs using xml tags. His xml tags approach  
really simplified dialog creation. However, porting what he did for  
obveRsive to R Tcl/Tk would be a very difficult task, but one that is  
worth considering.

  My final opinion (which is focused on the R Tcl/Tk package) is that  
having a limited and "ugly," but working, set of widgets is much more  
important than having an extensive collection of "modern" widgets  
that behave badly, or are only available for some OSs. This is not to  
say that I think no effort should be devoted to expanding the set of  
widgets available under the R Tcl/Tk package, rather, I think there  
is a need for a conversation and consensus about which additional  
widgets would likely provide the greatest improvement in GUI  
applications developed under R as a way of prioritizing any efforts  
in this area, and that the goal of these efforts should be to make  
the desired widgets available under all major operating systems on  
which R runs.

Overall, my belief is that R already has a number of useful tools for  
developing GUIs, and that there is probably much greater return to  
efforts to improve the usability of these existing tools than in  
developing completely new toolkits or developing an API from scratch  
as this moment in time.

My apologies for the length of this post.

Dan

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-SIG-GUI mailing list
R-SIG-GUI at stat.math.ethz.ch
https://stat.ethz.ch/mailman/listinfo/r-sig-gui