GUI support from R

"BE" == Byron Ellis <bellis@hsph.harvard.edu> writes:

    BE> All I'm saying is that before people go haring off on a bunch
    BE> of bindings for various graphics APIs (be it GTK, wxWindows,
    BE> Tk, Win32, OpenGL GUI or *whatever*) that it might be
    BE> advantageous to sit down at perhaps plan out a common set of
    BE> features that all work in a way that makes sense for *R* not
    BE> for Java or C++ or Tcl (AWT,Gtk+,Tk) and then go from there.

I'll argue the opposite, actually.  Best to have a bunch of prototypes
around and determine use-cases before deciding a particular something
is "the REAL deal".

Until you have a bunch of prototype applications sitting on the
prototype bindings, it'll be difficult to get it right.

(and yes, I've played with two, so far, Swing bindings via RSJava and
the tcltk ones...).

I suspect that the favorite of anyone will be "whatever they are used
to".  

best,
-tony

I think tony is right.  Ideally, we want eventually to have a
hight-level, toolkit and OS independent interface, if that is
possible.  It may turn out that some things are too difficult to make
work cleanly across systems without going to a common denominator that
is too low; in those cases we would like a clean way of describing the
differences.  Unfortunately it isn;t possible to build such things in
the abstract--you need some prototypes to gain experience.

Also, one thing I have learned in may years of experience with this
sort of thing in xlispstat is that for a language like R any good GUI
system requires a proper mechanism for managing concurrency, in other
words: concurrent thread support (this is one thing Java definitely
got right).  Without that you end up either reinventing a significant
fraction of a threading system or with nasty race conditions, or both.
Threading for R is being worked on, but it is going to be a while
until it is ready to go.  It makes sense to experiment with a variety
of GUI designs in the interim and then look at tying things together
when all the pieces are in place.

One area where we can help is by separating the drawing and the event
management in the R graphics devices so that it is possible for R to
use its own drawing code for putting ink on paper but let a toolkit
take over the event management (in the long run I think this may be
more viable cross platform than trying to fight the multiple event
loops battle).  This sort of thing is useful in other contexts as
well, in particular in embedding, and it is being worked on.

luke

Luke Tierney
University of Minnesota                      Phone:           612-625-7843
School of Statistics                         Fax:             612-624-8868
313 Ford Hall, 224 Church St. S.E.           email:      luke@stat.umn.edu
Minneapolis, MN 55455 USA                    WWW:  http://www.stat.umn.edu


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