[R-gui] Re: R-SIG-GUI digest, Vol 1 #3 - 9 msgs

[Duncan Temple Lang]

(Sorry Peter, I sent my mail only to you.)

And, in the same spirit as Peter, I'll just tag my comments onto his
mail.

While Tcl/Tk is the best tested of the R gui bindings, that is
partially because it was added directly to the R source rather than
provided as a package as the other interfaces have.  As a result, it
has received a lot of attention on the configuration aspects,
etc. from developers and users. I think it would be very useful to
give some of the other packages the same sort of attention. 

As Tony Rossini mentioned, there is the RGtk package which 
provides an S-language connection to the Gtk widgets and event
handling, etc.

There were several reasons for doing the Gtk bindings for R.  I
believe that Gtk has far more momentum than Tk or indeed many other
toolkits. As the cornerstone of Gnome, it gets a lot of attention and
a multitude of new widgets that are added externally or in Gtk 2.0,
etc.  The fact that Sun and HP (I think my memory is correct) have
announced that they will use Gnome as their desktop in the next major
release of their OSes illustrates that there is some belief it will be
here for a while and get more attention.  It might be a little
simplistic, but one might say that Tk is tried and established but old
and Gtk/Qt/Cocoa, etc. are the new and modern toolkits that will be
with us for the medium term.

 The connectivity with the different Gnome tools such as Gnumeric,
AbiWord, Dia, etc. makes it easy for us to develop plugins written in
R for those applications. This essentially allows us to put statistics
into everyday office applications. (The use of XML also helps here a
lot since that is the output format these tools use.)  One of the
benefits of Gtk is that it provides compile time and run-time
reflectance, so the bindings (and future bindings) are generated
automatically with S code. There is no manual effort needed.

I have used the Gtk mechanism to get the Rggobi link working.  Also,
with the connectivity to Gnome, the Orbit/CORBA connection is
relatively natural (and hence structured high-level distributed
computing). 


Tk is not a bad toolkit at all but the extensions are a lot more
decentralized than those for Gtk. One of the main problems with using
Tk I feel is that we have to go through Tcl. That is not an ideal
programming language for our purposes by any stretch of the
imagination. Indeed, we have a language that we can assume all the
players involved are familiar with - i.e. S itself.  Scripting is
essential, but scripting in a lot of different and less familiar
languages won't make it easy for a community to move forward and
maintain any GUI material we develop.  There are not very many large
applications built on Tk relative to the number of professional Gtk
applications.  

We already have a Gtk graphics device as a separate package.  GtkHTML
and Mozilla Embedded provide different HTML renderers.  Deb Nolan and
I have been using GtkHTML to display documents that contain arbitrary
Gtk widgets, giving us live interactive documents that make nice
interfaces for teaching or interactive publishing.  One can use
gtk+extra to implement a data editor. Alternatively, we have RGnumeric
which allows us embed R in the Gnumeric spreadsheet. 


So what Peter said is absolutely the most important thing to focus on:

> We really need to make sure that we
> create the proper abstractions for the job, so that we can concentrate
> on a few key routines.

This is key. No matter what each of us believes about the merits of
the different toolkits, as a community, we will need probably all of
them, i.e. Tk, Gtk, Cocoa, Swing and probably Qt (which we can
probably generate automatically using SIP).

What we should probably move forward on is developing small
stand-alone tools that we can combine into an IDE.  As we develop
invividual tools such as object browsers (see BioConductor), code
displays, debuggers, model builders, etc., the different idioms will
become apparent and we can figure out the abstractions for the S
language level.  And we will get an understanding of what the tools
should look like. (If they aren't programmed in S, I imagine fewer
people will experiment with modifying them and trying new interface
designs.  So it would be good to use the existing toolkits if possible
or work on providing bindings for them.)

Building a complete system and expecting others to adopt it as the
"unique" GUI is likely to be unsuccessful because of all the pratical
problems people have mentioned. There are too many diverse user
communities and applications within the R world.  Building an
abstraction for the existing toolkits so that one can use essentially
the same code with different toolkits attached would be a great
achievement and set us up for whatever new toolkits come in the
future.

One technical step in the abstraction is the ability to handle
different event loops within R, e.g to use Tk's, Gtk's or Carbon's
event loop.  There is an experimental package - REventLoop - at
http://www.omegahat.org/REventLoop that does this.  If people could
give it a try and let me know what problems (or success) they
encounter, we can push on integrating that into R itself and getting
it running with the Windows and Carbon event loop.s


One other remark since I don't get much time to write these mails and
it came up in somebody's mail on this last last week.  The need for
pipes, etc. to communicate between the GUI and R doesn't seem like a
necessary or good approach. Tk, Gtk, etc.  are all accessible directly
in R and can callback to S functions, etc. We don't want to be
communicating with R commands sent as strings.  This is a very
limiting and tedious design. All the escaping that Peter mentions in
the tcltk package illustrates the problems with dealing with a
programming language entirely in strings. There are many computations
one simply cannot do, and even more that are very cumbersome because
of that interface.

Sorry for the length of the mail. 

 D.



Peter Dalgaard BSA wrote:
> Mark Myatt <mark@myatt.demon.co.uk> writes:
> 
> > List,
> > 
> > Sorry for jumping in the middle of a discussion. I have been in the
> > field for some time and have only just got back.
> 
> Also let me chime in briefly. I've had various other stuff on my mind
> lately, so I haven't really been up to making any kind of grand policy
> statements. This is not really a reply to Mark, I'll just cut his post
> up mercilessly so as to provide cues for some of the things that I'd
> like to say...
> 
> > Philippe Grosjean, I think, wrote:
> > 
> > >>For the graphical toolkit, it is certainly time to get a clearer idea of
> > >>which one is the most suitable among Tcl/Tk (+ Tix), Gtk, QT, wxWindows,...
> ...
> > 
> > My tendency would be to explore how far we can go with Tcl/Tk 
> 
> 
> Mine too, obviously, although maybe for other reasons: I think it is
> important to have the GUI scriptable in R, and the Tcl/Tk model is the
> best tested one out there, and cross-platform except for some
> low-level issues. 
> 
> I do occasionally have doubts, though. Sometimes the Gtk approach and
> all its promises about integration with other tools looks attractive,
> but I still think we need the internal scriptability. Some efforts in
> that direction are gnocl (Tcl interface in the style of Tk) and stklos
> (object-oriented Scheme interface). However, both of these are in
> their infancy, and essentially one-man jobs.
> 
> My general mode of operation has been to concentrate on getting the
> R/Tcl interface right and worry less about actually constructing
> applications, although I do currently have a student working on
> implementing a model-builder tool. The two next things I have on the
> agenda are to get an interface to TkTable working, and to employ Tcl
> object in the inter-language communication. The former would
> essentially give us a data editor for free, and the latter eradicate a
> lot of "quoting hell" that is currently going on in the .Tcl()
> function. After that, probably have another look at implementing a
> graphics driver for Tk canvases (or the zinc extension).
> 
> 
> > I think that the ScITE editor offers similar functionality in an open
> > source bundle. I think we need to be clear about what we mean by 'free'.
> > I think this has to mean something like the GPL. You can do all of this
> > stuff by overloading a standard Tcl/Tk text-widget.
> 
> ..cue the ctext text widget extension,
> http://www.xmission.com/~georgeps/ctext/ 
> 
> > I seldom use the data-browser in R mostly because I do most data-entry /
> > management outside of R. I am not sure how important a spreadsheet is.
> 
> It's important alright. For keeping users warm and fuzzy, giving them
> the feeling that they can see what data they are operating upon... 
>  
> > >>- A decent rich text editor with embedded graphs, etc... and I find the
> > >>standard richedit.ocx suitable.
> > 
> > I suppose this could be done with HTML or XML.
> 
> TkTable also allows all sorts of embeddings, see e.g.
> http://jfontain.free.fr/moodss/ which builds upon it
> 
> > >>- A html browser,... and the Internet Explorer ocx is performing well
> > >>(arrghl).
> > 
> > More of these than you can shake a stick at ... Mozilla is popular ...
> > From what I am told, Mozilla / Penzilla with XUL good do the entire GUI
> > thing from within the browser.
> 
> TkHtml, if the purpose is just to display simple stuff.
> 
> > >>Yes, I know! You want to kill me now! Perhaps, an alternative would be to
> > >>convince me that I will find similar features in other graphical toolkits?
> > 
> > The problem with all this is that it is very much Windows based and I
> > think we should address UNIX (and derivatives such as Linux, MacOS X)
> > systems as well. This means we are restricted to cross-platform tools
> > and have to choose the best available.
> 
> Yes.
>  
> > The other thing that nags me is that we should try and make the UI as
> > light as possible. I can imagine a situation where the size of the UI
> > (including support libraries) comes to several times the size of the R
> > engine and has a huge processing overhead. Let us avoid bloat.
> 
> I appreciate the sentiment, but I'm not really sure I agree. The main
> risk of bloating is on Windows, where support libraries are not
> available as part of the OS, and considering the fact that people are
> prepared to accept a SAS ("minimal"!) installation of close to 1GB, I
> think we have some headroom (sometimes I even tend to think that we
> should ship the whole *ing GCC/Perl development system along with the
> R binaries, rather than try to teach people how to download and
> install it). Most Linux distros come with the relevant libraries, so
> are not a problem, leaving essentially the group of older Unixen
> (Solaris, HP-UX, Irix) with a problem of installing a portfolio of
> tools, but there we already assume that people would be willing to
> install libjpeg, gnu tool, etc, etc.
> 
> What we really want to avoid is "bloat by repetition", 200 routines
> doing almost the same thing in the same way (so that if you decide to
> do the same thing in a different, better, way, you'll have 200
> routines to fix up every time). We really need to make sure that we
> create the proper abstractions for the job, so that we can concentrate
> on a few key routines.
> 
> 
> -- 
>    O__  ---- Peter Dalgaard             Blegdamsvej 3  
>   c/ /'_ --- Dept. of Biostatistics     2200 Cph. N   
>  (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
> ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk)             FAX: (+45) 35327907
> _______________________________________________
> R-SIG-GUI mailing list
> R-SIG-GUI@stat.math.ethz.ch
> http://www.stat.math.ethz.ch/mailman/listinfo/r-sig-gui

-- 
_______________________________________________________________

Duncan Temple Lang                duncan@research.bell-labs.com
Bell Labs, Lucent Technologies    office: (908)582-3217
700 Mountain Avenue, Room 2C-259  fax:    (908)582-3340
Murray Hill, NJ  07974-2070       
         http://cm.bell-labs.com/stat/duncan