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

[Zed A. Shaw]

I'm a bit confused.  I thought the purpose of this mailing list was to help
people out who are designing various graphical user interfaces (either front
ends or widget bindings or both).  I did not realize that it was to help
create an entire IDE in R using every toolkit imagined.  My impression of
the conversation so far has been towards how best to get everyone to use Tk,
GTK+ or whatever through an R binding.  This seems a rather narrow focus in
my opinion, but maybe I'm wrong about the conversation (probably).

What *I* would like to really see discussed is why it is so damned hard to
get R to work as a proper backend.  I think creating an R "server" that was
accessible from CORBA, XML-RPC, etc. and ran R code reliably (without
crashing every two seconds because it's not in "interactive" mode) would do
a lot more for GUI development than anything discussed so far.  If there is
already a GTK+/Orbit thing that does this, then I think making it generic
(read, NOT GTK+ specific) and providing it as a means of integrating R with
different languages would be fantastic.  I imagine this would give you the
largest bang for your buck as far as development time vs. benefit to the
community.

But, if I'm wrong, and the purpose is to create an IDE and a billion
different bindings to everything, then I'll just keep quiet.

Zed


On 10/17/02 10:53 AM, "Duncan Temple Lang" <duncan@research.bell-labs.com>
wrote:

> 
> 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.)
> 
-- 
Zed A. Shaw