From putler at sauder.ubc.ca  Mon Oct 17 10:39:24 2005
From: putler at sauder.ubc.ca (Dan Putler)
Date: Mon, 17 Oct 2005 01:39:24 -0700
Subject: [Rd] [R-gui] R GUI considerations (was: R, Wine,
	and multi-threadedness)
In-Reply-To: <4660.138.217.40.89.1129433261.squirrel@homebase.wehi.edu.au>
References: <4350FB09.3020503@sciviews.org>
	<4660.138.217.40.89.1129433261.squirrel@homebase.wehi.edu.au>
Message-ID: <6822F815-105F-4749-93F8-F9295EE543A9@sauder.ubc.ca>

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

On 15-Oct-05, at 8:27 PM, 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-SIG-GUI mailing list
> R-SIG-GUI at stat.math.ethz.ch
> https://stat.ethz.ch/mailman/listinfo/r-sig-gui
>



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