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

[Peter Dalgaard BSA]

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

> Peter Dalgaard BSA <p.dalgaard@biostat.ku.dk> writes:
> 
> >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.
> 
> I am not sure whether you are being personal with the use of "you" in
> the above. I will, however, cast my reply in personal terms ... What is
> stopping ME from getting my hands dirty is that, without agreement that
> this is the way to go, it might be a lone enterprise which will amount
> to so much wasted effort. If there is agreement amongst some of us that
> this is the way to go then I will do what I can to help the effort.

That was actually meant as an impersonal "you"... In general, I think
some of the emotions that got stirred up comes from the sentiment that
we necessarily have to agree here and now about what to do, which is
not at all what I feel is a good way to use an SIG. Rather, I thought
that the purpose of the list would be to bandy ideas about regarding
UI matter large and small. 

I don't think that anything will happen until a small group of 1-4
people with similar ideas about how things should work sit down and
make a prototype where at least some things do work. Then others might
start chipping in if they can see that useful things can be added with
relatively minor effort.

Personally, I definitely want to keep developing the Tcl/Tk interface,
if for nothing else out of intellectual curiosity. At least for a
while until I know its limitations better. I don't worry too much
about wasting efforts, most of the problems that I have been bumping
into have been interesting enough in themselves (and no more futile
than chasing down floating point compiler errors with some versions of
GCC on some types of Alpha computers...). If you have suggestions
about what would be good to have in that interface (or maybe more to
the point: how to implement it) you'd be most welcome.
 
> >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
...
> I have not got into R below the language level and I have been guilty of
> the ESS approach myself.

That is of course a natural first approach. It's just that if you can
avoid going through a textual representation it is usually worth it.
The current tcltk interface has a similar weakness since it builds Tcl
commands as strings and has to deal with Tcl's quoting mechanisms. And
as Tony pointed out, it is not the fault of ESS as such: there could
be hooks that allowed R to be aware of the emacs shell and let a more
direct communication take place.

> >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.
> 
> These are details ... I rather like a resource file approach since
> configuration can be done in an editor rather than requiring function
> calls. I am not sure how essential is the ability to add menus and items
> on the fly. I think most users will be happy to stick with menus as
> defined at application start.

I do actually think it is essential. R is a modular design, and it
isn't possible to define in advance what a package might wish to
contain in terms of user interface. Certain things might be boiled
down to a static description that could sit in an external file or in
an R data structure, but not all. How would a dynamic graphics
package like ggobi (um, tkgobi?) fit in for instance? Programmability
has been *the* key to the success of the S languages, so why should we
discard the possibility of making our user interfaces programmable?

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