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

[Duncan Temple Lang]

Hi Zed.

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

I was hoping that we could start small and focus on the interfaces,
regardless of how they are implemented.  However, to get the most
number of people to be able to experiment with them, modify them,
etc. it will be best to pick a common programming language which is R.
If anyone wants to build something with R as an external server or an
embedded library, that's great.  Speaking from experience, there are a
lot of details to get users to configure this. They have to build R as
a shared library or run R as a DCOM or CORBA server. This has proven
to be complex for many people. Pity!  That's why I think using the
existing bindings (or creating new ones) gives us the best chance to
focus on the interface itself and give us a means to discuss things in
a common language.


> 
> 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 it is hard to get it configured on other people's machines.
But I don't think it is technically too hard to get it to work as a
regular server. What are the problems you have encountered.  (I agree
things could be better and have some plans to make it easier and more
platform independent, but they do involve significant reorganization
of code.)


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

Luke Tierney has a simple example to show how to do this with sockets.
I do it by embedding things as a shared library and simply by pass the
interactivity issue (just calling R_tryEval()).

Can you point me to GUIs that are developed as clients to a server
running in a different process. Most of the Perl, Python, etc. GUIs I
have seen are done via bindings to Tk, Gtk, Qt, etc and loaded into
the Python process. The separation of interface and callback code is a
good thing, but I haven't seen it taken to this level of separation
commonly. I'd be interested in seeing how responsive and expressive it
was.
 

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

I did that a long time ago and the silence on the user end was
deafening! People weren't ready for CORBA as there was too much choice
and not enough need. Things may better now, but who knows.  And a
general DCOM/CORBA interface would presumably involve just an
evalThisString() method which, as I mentioned, is very limited.  (What
about return values?)



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

Please don't. That would be a loss.  I think we really want people to
explore interfaces and different approaches and it seems like you have
good and different ideas.

So, really my point was that we will need to support multiple toolkits
and we shouldn't dwell on selecting one. Rather doing things that we
can easily experiment with and discuss.  As Duncan (Murdoch) said in
another response, we'll figure out how to port things later.


 D.


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