[Rd] RE: [R] GUI support from R

[Byron Ellis]

IMHO the wrong question is being asked here---it is not a matter of
underlying toolkit. We could literally spend the rest of our lives arguing
over toolkit, especially since toolkits come in and out of fashion (X
widget sets come to mind...), stopped being developed and start again
(wxWindows had a period of stagnation if I recall) or undergo radical
changes (gtk as mentioned). Rather I think what really needs to be decided
is a uniform R level mechanism for GUIs, something philisophically to
Java's AWT design. In the AWT case, the underlying aspects of the Java
toolkit representation are implemented using the appropriate system-level
toolkit (Motif on UNIX, Win32/GDI on Windows,
I-Forget-The-Name-of-the-MacOS-Windowing-API and so on). Once that toolkit
has been established then discussions over underlying toolkit become moot
except for people who want to maintain R's GUI facilities on platform
foo. The traditional graphics implementation already does this to some
extent at the "C" level (though I would advocate the abstraction of the
graphics devices into the R level making them packages rather than
integral to the system. In other words, devices would be implemented as a
class derived from a particular virtual base) so it seems reasonable to do
the same thing for GUIs and interactive graphics.

Byron Ellis (bellis@hsph.harvard.edu)
"Oook" - The Librarian

On Sun, 2 Sep 2001, Nicholas Lewin-Koh wrote:

> 
> Hi,
> One thing to note is that GTk development is in a state of
> transition. They are moving steadily towards GTK 2.0 which involves many
> changes in Glib, Gdk  and the underlying private functions. James
> Hesteridge who is the maintainer of pygtk is actively working on
> integrating all the changes into the next version which is why thre hasn't
> been a release in a while.
> 
> The nice feature of gtk vs wxwindows is that gtk is written entirely in C
> while wxWindows is C++. My understanding is that there is byte
> incompatibility between different compilers for C++, meaning that C++ code
> compiled with VC++ cannot be combined with c++ code compiled with gcc. I
> don't know how this affects modules loaded into python.
> 
> There is a very complete comparison of GUI toolkits at 
> http://www.geocities.com/SiliconValley/Vista/7184/guitool.html
> 
> anyway my 2c
> 
> Nicholas
> 
>  On Sat, 1 Sep 2001, Warnes, Gregory R wrote:
> 
> > Hi Duncan,
> > 
> > I've been looking around at GUI toolkits to use with Python (and by
> > extension R). I initially tried Tk, but was disappointed because there is no
> > consistent set of high level widgets.  I've subsequently done some looking
> > at QT, wxWindows, and GTK.  QT is out because I am a *commercial* user, and
> > I don't want to have a license hassle.  GTK seemed to have a lower level of
> > functionality than wxWindows and seemed to be less platform independent.
> > >From what I could see, the on-line documentation to wxWindows was better. In
> > addition, the wxPython developer has indicated that the wxWindows
> > development team is very supportive.
> > 
> > I was also very pleased that wxWindows handles printing, and it had a nice
> > set of high-level widgets as part of the 'base' library.  There seem to be
> > some high level widgets for GTK, but they are 'add-ons' and seem less well
> > integrated or supported.  
> > 
> > Also, looking around at the 'embarrassment of riches' among Python GUI
> > toolkits, I've come to the conclusion that it is better to have *one* GUI
> > library that is well supported than to have a set of them.  Our community is
> > really too small to fracture again into different toolkit users.  Perhaps a
> > single set of high-level bindings would do the trick, but I worry that not
> > enough functionality would be available at that level of abstraction.
> > 
> > BTW, wxWindows uses GTK as the backend on Unix, so you may still be able to
> > control gtk-based components that are written in GTK. 
> > 
> > I'm very interested in the GUI issue because I am currently building a GUI
> > tool that will use R as the computational backend.  It would be really nice
> > if I could do the GUI building and control directly in R rather than using
> > Python.  It would make one less language to learn & manage for me and for
> > other users/developers.
> > 
> > And, I really do need some of the high level widgets and functionality
> > offered directly by wxWindows, but (as far as I can tell) not by GTK.
> > 
> > -Greg
> > 
> > -----Original Message-----
> > From: Duncan Temple Lang [mailto:duncan@research.bell-labs.com]
> > Sent: Monday, August 27, 2001 11:14 AM
> > To: Warnes, Gregory R
> > Cc: 'Duncan Temple Lang'; rossini@u.washington.edu; nychka@cgd.ucar.edu;
> > r-help@stat.math.ethz.ch
> > Subject: Re: [R] GUI support from R
> > 
> > 
> > Warnes, Gregory R wrote:
> > > 
> > > Hey Duncan,
> > > 
> > > Can you share with us the reason for selecting GTK?  
> > 
> > Well there are a few basic reasons.
> > 
> > I know less about wxWindow than I do about Gtk.  And there is a lot
> > less to Gtk than to wxWindows.  So that makes it is easier for me to
> > think about the bindings. (Also, Gtk is like X, and I spent a fair bit
> > of time desigining and developing S bindings for X and different
> > widget sets a long time ago.) The additional features of wxWindows
> > such as threads, etc. may get in the way in thinking about how Gtk
> > bindings relate to, Tcl/Tk, Java, and other GUI toolkits.  It would be
> > nice to have a level of abstraction above these toolkits with the
> > ability to select one and use the same code for all.
> > 
> > My "hope" is to be able to use Slcc to programmatically generate 
> > bindings for Gtk. This will be easier given that I know
> > my way around some of the Gtk code. However, if it works,
> > applying the same programmatic approach to wxWindows
> > should give us 80% of the grunt work for free and then
> > require some tinkering later.
> > 
> > Importantly, the applications I have in mind for RGtk are things like
> > extending Gnumeric with plugins, programming GGobi events and even
> > add-ons, and generally interacting with many of the Gnome tools
> > including potentially building a GUI for R to replace the C-level
> > Gnome code with R scripts, making it more flexible and adaptable.
> > If we use wxWindows for these Gtk-based applications, we are adding
> > an extra layer between R and the application that will probably be
> > confusing.
> > 
> > If we do get to the level of abstraction across toolkits, it won't
> > matter much which toolkit we use, but will only require bindings to
> > the ones of interest. The challenge then will be to allow integrating
> > widgets from different toolkits, and that can be tricky on some
> > platforms.
> > 
> > So, I am in no way ruling out wxWindows. In many respects, it looks
> > more appealing - just too big at present. What is its development
> > energy like relative to Gtk. I am very happy to work on wxWindows
> > too. There is very little in the RGtk at present.
> > 
> >  D.
> > 
> > 
> > > 
> > > -Greg
> > > 
> > > 
> > > LEGAL NOTICE
> > > Unless expressly stated otherwise, this message is confidential and may be
> > privileged. It is intended for the addressee(s) only. Access to this E-mail
> > by anyone else is unauthorized. If you are not an addressee, any disclosure
> > or copying of the contents of this E-mail or any action taken (or not taken)
> > in reliance on it is unauthorized and may be unlawful. If you are not an
> > addressee, please inform the sender immediately.
> > >
> > -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
> > -.-
> > > r-help mailing list -- Read
> > http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
> > > Send "info", "help", or "[un]subscribe"
> > > (in the "body", not the subject !)  To: r-help-request@stat.math.ethz.ch
> > >
> > _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._.
> > _._
> > -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
> > -.-
> > r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
> > Send "info", "help", or "[un]subscribe"
> > (in the "body", not the subject !)  To: r-help-request@stat.math.ethz.ch
> > _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._.
> > _._
> > -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
> > r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
> > Send "info", "help", or "[un]subscribe"
> > (in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
> > _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
> > 
> 
>                  CH3
>                   |
>                   N             Nicholas Lewin-Koh
>                  / \            Dept of Statistics
>            N----C   C==O        Program in Ecology and Evolutionary Biology
>           ||   ||   |           Iowa State University
>           ||   ||   |           Ames, IA 50011
>           CH    C   N--CH3      http://www.public.iastate.edu/~nlewin
>             \  / \ /            nlewin@iastate.edu
>              N    C
>              |   ||             Currently
>             CH3   O             Graphics Lab
>                                 School of Computing
>                                 National University of Singapore
>      The Real Part of Coffee    kohnicho@comp.nus.edu.sg
> 
> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
> r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
> Send "info", "help", or "[un]subscribe"
> (in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
> _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
> 

-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._