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

[Byron Ellis]

On 2 Sep 2001, A.J. Rossini wrote:

> >>>>> "BE" == Byron Ellis <bellis@hsph.harvard.edu> writes:
> 
>     BE> IMHO the wrong question is being asked here---it is not a
>     BE> matter of underlying toolkit. We could literally spend the
>     BE> rest of our lives arguing over toolkit, especially since
>     BE> toolkits come in and out of fashion (X widget sets come to
>     BE> mind...), stopped being developed and start again (wxWindows
>     BE> had a period of stagnation if I recall) or undergo radical
>     BE> changes (gtk as mentioned). Rather I think what really needs
>     BE> to be decided is a uniform R level mechanism for GUIs,
> 
> I think the primary problem is writing it in the first place.  
> 
> There is access to AWT and Swing, via RSJava (when it's feeling
> stable... sigh...).

Right, but this relies on not only an outside package, but another
language entirely. A hefty one at that.

> 
> There is the tcltk toolkit, which we are having some success using,
> actually (menu's, etc).
> 
> You can argue about the merits of anything all you want, but he who
> codes first wins in this game.  And is stuck with having to maintain
> it, if they plan on anyone else using it...
> 
> I think this is the big issue.  No one has much time, and this is a
> big time sink, especially with multiple moving targets (R vs "threaded
> R", event loops; various GUI API changes; supporting libraries; lots
> of other critical issues which are obvious enough not to state...).  I
> think it'll take a hacker with Brian or Duncan's skills to craft it
> fast enough to not let it get stuck.

Ok, you're giving more reasons to develop a binding that is robust enough
to survive changes--not a reason to get stuck with package foo version
0.whatever that only works properly on a few platforms.

> 
> While a uniform API would be nice for R, to attach to any toolkit, I
> suspect it is non trivial.  There are movements/projects like "AnyGUI"
> for Python, which are attempting to be flexible over a choice of
> toolkits from a single set of code.  However, it seems that every GUI
> API has its own unique twists on layout, etc, that make this
> seriously non-trivial.

Yes, and every GUI backend has its own twists that are just bad enough to
completely derail things like GTK porting projects let alone the language
bindings. You have in fact hit upon the exact reason why a reasonably
defined binding for the R language would be a good idea: No Matter What
Package You Pick It Will Suck On Some Platform. 

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

> 
> Best just to pick one and go...
> 
> best,
> -tony



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

	
> 
> -- 
> A.J. Rossini				Rsrch. Asst. Prof. of Biostatistics
> U. of Washington Biostatistics		rossini@u.washington.edu	
> FHCRC/SCHARP/HIV Vaccine Trials Net	rossini@scharp.org
> -------- (wednesday/friday is unknown) --------
> FHCRC: M-Tu : 206-667-7025 (fax=4812)|Voicemail is pretty sketchy/use Email
> UW:    Th   : 206-543-1044 (fax=3286)|Change last 4 digits of phone to FAX
> 
> 

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