[R-gui] R GUI considerations (was: R, Wine, and multi-threadedness)
Dan Putler
putler at sauder.ubc.ca
Mon Oct 17 10:39:24 CEST 2005
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
>
More information about the R-SIG-GUI
mailing list