[R-gui] Re: R-SIG-GUI digest, Vol 1 #18 - 5 msgs

[Peter Dalgaard BSA]

Mark Myatt <mark@myatt.demon.co.uk> writes:

> All,
> 
> Regarding using Tk, Thomas Friedrichsmeier writes
> 
> >The problem I see with this, is that this will be fine for the approach
> >"extend R to have a GUI", but is simply not useful for the approach "write a
> >GUI around R" (i.e. with R as a true backend). In fact, I think it would be a
> >good idea to develop these custom Tk widgets for R, you mention, but I'm
> >afraid, if we really want something useful across many different projects,
> >we'll have to use some more abstract standard.
> 
> A good point. I was thinking more of a split development effort in which
> there was some form of GUI shell around R with (e.g.) menus customisable
> though a simple text file that describes menu names and hierarchies and
> specifies calls to R functions as well as turning on and off various
> aspects of the GUI. Such a GUI could have things like window management,
> an embedded code editor component, a tabular data-editor / viewer, and
> an 'object inspector'. This would be the "GUI around R". Front ends to
> functions (called from menus or from the command line) could be written
> in R controlling a Tk drawn dialog. 
[...]
> 
> In addition, we already have the Tk interface (mostly) up and running.
> It seems a bit of a shame to put this maturing development aside and
> start anew.

Well, it's not like the interface has been a whole lot of programming,
so if there are better ways we should be open towards them (the
thinking effort has not been quite vanishing though...). I'm more
worried that we'd be missing some opportunities for using preexisting
code (we don't need to rewrite the text widget or tkTable!) and end up
with poor solutions to problems that have already been solved better
by others.

To the above discussion, just let me add that there is nothing in
principle keeping you from writing a substantial body of GUI code as
Tcl functions and call those from R, nor is it impossible -- although
what is in the current implementation is rudimentary at best -- to
reverse the roles of the two languages and make calls from Tcl into R.
You could in fact have R load as a Tcl extension, while still
retaining the possibility for the embedded R to add GUI elements, etc.

There is really a lot of stuff in Tcl that is not immediately obvious,
but is designed exactly to make this sort of thing possible. Multiple
interpreters and the possibility of aliasing commands between them for
instance. Using this, you could (fairly) easily run multiple embedded
applications in the same general Tcl/Tk framework. They don't even all
need to be implemented in the same way; some could be straight
standard i/o applications while others integrate more tightly.

I don't think it is all that crucial whether you do things one way or
the other (R from Tcl or Tcl from R); the only really sticky issues
that I see are associated with the intertwining of event loops,
issuing a locator() call while retaining the ability to navigate
menus, etc. and they are sticky whichever way you turn the interface.
I suspect that there's not going to be a neat solution of that without
some form of multithreading. [There are issues even without an actual
GUI, just try something like "boxplot(1:10); help(boxplot)" under X11
and notice that the plot doesn't redraw until you terminate the help
pager.]

The basic thing to avoid is the "ESS approach" (don't get me wrong,
some of my best friends are ESS users ;-) ) where the interface must
try to learn about the internal state of R by parsing printed output
(and then make the command and its output disappear from the eyes of
the end user). There needs to be a direct interface at the level of
the language objects.

I'm not all that happy with the idea of encoding menu structures in
external files either. I really do think that you need a handle on
(say) the system menubar, so that a function can say "Please add these
items to the toplevel menu", etc. However, there is not necessarily a
contradiction between the two - the R side can edit the XML
description and ask the GUI shell to reload it; it just feels a bit
clunky.

-- 
   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