List,
Sorry for jumping in the middle of a discussion. I have been in the
field for some time and have only just got back.
Also let me chime in briefly. I've had various other stuff on my mind
lately, so I haven't really been up to making any kind of grand policy
statements. This is not really a reply to Mark, I'll just cut his post
up mercilessly so as to provide cues for some of the things that I'd
like to say...
Philippe Grosjean, I think, wrote:
For the graphical toolkit, it is certainly time to get a clearer idea of
which one is the most suitable among Tcl/Tk (+ Tix), Gtk, QT, wxWindows,...
...
My tendency would be to explore how far we can go with Tcl/Tk
Mine too, obviously, although maybe for other reasons: I think it is
important to have the GUI scriptable in R, and the Tcl/Tk model is the
best tested one out there, and cross-platform except for some
low-level issues.
I do occasionally have doubts, though. Sometimes the Gtk approach and
all its promises about integration with other tools looks attractive,
but I still think we need the internal scriptability. Some efforts in
that direction are gnocl (Tcl interface in the style of Tk) and stklos
(object-oriented Scheme interface). However, both of these are in
their infancy, and essentially one-man jobs.
My general mode of operation has been to concentrate on getting the
R/Tcl interface right and worry less about actually constructing
applications, although I do currently have a student working on
implementing a model-builder tool. The two next things I have on the
agenda are to get an interface to TkTable working, and to employ Tcl
object in the inter-language communication. The former would
essentially give us a data editor for free, and the latter eradicate a
lot of "quoting hell" that is currently going on in the .Tcl()
function. After that, probably have another look at implementing a
graphics driver for Tk canvases (or the zinc extension).
I think that the ScITE editor offers similar functionality in an open
source bundle. I think we need to be clear about what we mean by 'free'.
I think this has to mean something like the GPL. You can do all of this
stuff by overloading a standard Tcl/Tk text-widget.
- A html browser,... and the Internet Explorer ocx is performing well
(arrghl).
More of these than you can shake a stick at ... Mozilla is popular ...
From what I am told, Mozilla / Penzilla with XUL good do the entire GUI
thing from within the browser.
TkHtml, if the purpose is just to display simple stuff.
Yes, I know! You want to kill me now! Perhaps, an alternative would be to
convince me that I will find similar features in other graphical toolkits?
The problem with all this is that it is very much Windows based and I
think we should address UNIX (and derivatives such as Linux, MacOS X)
systems as well. This means we are restricted to cross-platform tools
and have to choose the best available.
Yes.
The other thing that nags me is that we should try and make the UI as
light as possible. I can imagine a situation where the size of the UI
(including support libraries) comes to several times the size of the R
engine and has a huge processing overhead. Let us avoid bloat.
I appreciate the sentiment, but I'm not really sure I agree. The main
risk of bloating is on Windows, where support libraries are not
available as part of the OS, and considering the fact that people are
prepared to accept a SAS ("minimal"!) installation of close to 1GB, I
think we have some headroom (sometimes I even tend to think that we
should ship the whole *ing GCC/Perl development system along with the
R binaries, rather than try to teach people how to download and
install it). Most Linux distros come with the relevant libraries, so
are not a problem, leaving essentially the group of older Unixen
(Solaris, HP-UX, Irix) with a problem of installing a portfolio of
tools, but there we already assume that people would be willing to
install libjpeg, gnu tool, etc, etc.
What we really want to avoid is "bloat by repetition", 200 routines
doing almost the same thing in the same way (so that if you decide to
do the same thing in a different, better, way, you'll have 200
routines to fix up every time). We really need to make sure that we
create the proper abstractions for the job, so that we can concentrate
on a few key routines.
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