Skip to content

R GUI considerations (was: R, Wine, and multi-threadedness)

27 messages · Gabor Grothendieck, Duncan Murdoch, Duncan Temple Lang +13 more

Original

Messages 1–25 of 27

Philippe GROSJEAN
# 
Hello,

Following a discussion initiated on r-devel, that mentions SciViews-R 
and other GUIs issues for R, I would like to make comments (and would be 
happy if these comments would initiate interesting initiatives).

A big, big problem with SciViews-R is that a part of it is written in 
Visual Basic 6, a M$$$$ language, not supported any more, buggy, non 
transposable to other platforms, etc, etc. Last year, I started to 
rewrite SciViews-R, using much more native R code, which will ultimately 
give what I call a "R GUI API", currently partly implemented in the 
SciViews bundle available on CRAN. That "R GUI API" is a lot of work: 
thousands of lines of code for the full API, and as I said, only a part 
of it is currently implemented. That API is developed with reusability 
in mind: platform-independent, better basis to rewrite SciViews-R in a 
different language, and freely available for use by other GUIs. However, 
nobody seems to be interested by this API (may be because it is not 
documented enough?). Even simple functions like progress() in the svMisc 
package are ignored, although they could be useful to some people. Well, 
I regret this situation, but I don't care much more than that: after 
all, the main goal is to make it the basis of the future 
platform-independent implementation of SciViews-R.

Now, regarding the rewritting of SciViews-R itself in a 
platform-independent environment (i.e., language + graphical widget), 
this is not undertaken currently for the reason I am not satisfied 
enough with all curerently existing solutions for various reasons. I 
give just a few explanations here:

1) R + Tcl + Tk. The tcltk R package is widely available and largely 
debugged. However, there are still problems to make a 100% Tcl console 
for R (look at Peter Dalgaard's attempt in the package, not complete, 
not 100% operational, currently). Another problem: the Tk widgets are a 
little bit old-fashion, and I miss a lot of features provided by more 
advanded graphical widgets like wxWidgets, for instance. However, it 
seems to be the best bet, currently. So, I explore various kinds of 
additions that could make Tcl + Tk a better and more modern GUI 
implementation. Look at http://www.sciviews.org/SciViews-R... the 
"tcltk2" package. In that package, I add "Tile", a series of themable 
and more modern widgets, the famous "tkTable", a tooltip widget, a text 
widget with synthax colouring, a tree widget, etc. + some Windows 
specific stuff that help regarding problems like focusing on a Tk 
window, and communicating with other apps. However, I face the problem 
of installing all these additional widgets seemlessly under all 
paltforms supported by R. For the pure Tcl widgets, no problems. But for 
widgets with compiled code, like Tile or tkTable, this is much more 
difficult... And since I mainly work on Windows...

2) wxWidgets. This is a really great, very capable and 
platform-independent solution. I like very much James Wettenhal attemps 
of using wxPython (wxWidgets + Python) through RSPython and the 
experimental wxPython R package. However, it is still alpha, there are 
problems to finalize it, and his author is not continuing its 
development for reasons that are personal to him. So, I am not sure we 
will have a usable version available soon to integrate wxWidgets with R 
and use it for a R GUI.

3) JAVA. There is a good R GUI written in JAVA: JGR. Moreover, something 
like the Eclipse platform is a very promizing environment for a 
rich-featured R IDE. JAVA specialists in my University say such a GUI, 
written in JAVA will be relatively slow compared to other solutions. 
However, JGR is a good actual counter-example.

4) GTK2. Great widgets... but forgets Windows. I installed and used Gimp 
under Windows. This is certainly the best demonstration on what can be 
done with GTK2 under Windows. I must admit I am very disappointed as a 
Windows user: look&feel is very different, and irritating in several 
aspects.

So, a long mail to conclude that, if I still haven't started to 
implement the platform-independent version of SciViews-R, it is because 
I am not convinced that any of the currently available R + rich-featured 
and platform-independent widgets solutions available is the one that 
will make it possible to reimplement SciViews-R in a streamless and 
relatively bug-free manner. To summarize, the currently best candidate 
is R + tcltk + tcltk2. I am convinced that R + Python + wxWidgets is by 
far a much better solution, but it is still in alpha development. 
Eclipse + JGR looks promising, and GTK2 is there too, but not enough 
integrated under Windows for me to start using such a solution, as a 
Windows user.

I don't have much time to dedicate to SciViews-R and to the Sciviews R 
GUI API for the moment, and I will certainly focus on four hot topics: 
(1) developing the actual SciViews-R as a better teaching aid (I use and 
need it for my own courses!), (2) contributing to the development of 
Tinn-R, (3) further integrating R Commander with SciViews-R, and (4) 
integrating Rpad with SciViews-R. However, I will have various contracts 
in 2006-2007 where the development of SciViews-R is a part of the job. 
So, I will have the opportunity to hire one or two developers, and this 
will hopefully speed up SciViews-R development in a directly that will 
satisfy more users.

Otherwise, I am open to any suggestion, and more importantly, to any 
idea of collaboration with other R GUI developers, as it is currently 
the case with John Fox (R Commander integration with SciViews-R), 
Jose-Claudio Faria (Tinn-R developement and Tinn-R compatibility with 
SciViews-R), and Tom Short (Rpad developments and compatibility with 
SciViews-R). I think it is important to insist on this, in a world 
populated with a myriad of slowly developed, half finished, half 
featured R GUIs, made by people that look too individualist in my view 
to be able of working all together and to write a single R GUI that has 
any chance to be full-featured, well-documented, reasonnably bug-free, 
truly platform-independent, in a near future.

Best,

Philippe Grosjean

..............................................<?}))><........
  ) ) ) ) )
( ( ( ( (    Prof. Philippe Grosjean
  ) ) ) ) )
( ( ( ( (    Numerical Ecology of Aquatic Systems
  ) ) ) ) )   Mons-Hainaut University, Pentagone (3D08)
( ( ( ( (    Academie Universitaire Wallonie-Bruxelles
  ) ) ) ) )   8, av du Champ de Mars, 7000 Mons, Belgium
( ( ( ( (
  ) ) ) ) )   phone: + 32.65.37.34.97, fax: + 32.65.37.30.54
( ( ( ( (    email: Philippe.Grosjean at umh.ac.be
  ) ) ) ) )
( ( ( ( (    web:   http://www.umh.ac.be/~econum
  ) ) ) ) )          http://www.sciviews.org
( ( ( ( (
..............................................................
Gabor Grothendieck
# 
The preferred solutions in the post all seem to involve another language:

- tcl to use tk
- Python to use wxWidgets

and other solutions mentioned also seem to involve other languages:

- Visual Basic
- Java (Swing?)

Is there some key missing feature in R with regards to GUIs
that requires interposing another language?
On 10/15/05, Philippe Grosjean <phgrosjean at sciviews.org> wrote:
Philippe GROSJEAN
#
Gabor Grothendieck wrote:
Yes, there is: R is designed for CLI, and this implies a different 
approach as for a GUI (sequential execution of commands versus 
event-driven application). A language more suitable for event-driven way 
of programming is thus often interposed between R and the GUI itself. 
Have you notice that none of "external" GUIs for R do all the job in R 
itself. Perhaps, the closest one from a 100% R coded GUI is R Commander, 
but it takes benefit from the specific event loop of tcltk (otherwise, 
the whole GUI would be completelly frozen during all R computations), 
and partly of Tcl (even if it is indirect). JGR is Java, SciViews-R is 
Visual Basic, Tinn-R is Delphi, RKward is C++, etc... Of course, it is 
possible to implement extensions in C directly within R (that is what 
RGui does), another altenative, not favoured by "external" GUI 
developpers, it seems.
best,

PhG
Gabor Grothendieck
# 
I notice that there is some discussion on this at
http://developer.r-project.org/ under the links involving the
word threading.  Thus using the facilities of another language
seems to be one approach and building such facilities into
R itself another.
On 10/15/05, Philippe Grosjean <phgrosjean at sciviews.org> wrote:
Duncan Murdoch
#
Gabor Grothendieck wrote:
I think the Java/C++ style of object oriented programming is 
particularly well suited to writing GUIs.  GUIs contain a lot of objects 
that need to maintain their state, and that need to respond to messages. 
  The different kinds of objects have a lot in common with one another, 
and also some specific differences.

You don't need an OOP language to write a GUI (the Windows Rgui is 
written in C, for example), but it makes things easier.

You can write R in that style, but it's not the standard style to use, 
so it's not particularly easy.

Duncan Murdoch
Duncan Temple Lang
# 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


I think it is a little premature to entirely discount
Gtk2, especially if it is based on Philippe's remark
below.  Philippe, did you try other applications,
different themes, different configurations, or just the vanilla GIMP?
and when? While I don't necessarily disagree with the claim that it is
different from Windows look and feel, it requires a little bit more
evidence.

When I complete the SWIG module for R and the associated
more advanced tools, I may pursue an automatically
created interface to wxWidgets that would by-pass the
RSPython dependency.

Unfortunately, many people have become more vested in
Tcl and sub-optimal solutions because it is there.
We need to keep pushing infrastructural development and
what is feasible.  For some of us, the collection
of widgets and the possibilities that they introduce
are more important than cosmetic details, which of
course are important but won't necessarily advance
the paradigms of analysis.

Philippe, while you think that people are to individualistic
in their development of GUIs, I think perhaps a better
interpretation is that many of us are trying to develop
GUIs quite different from what you have in mind.  Your mail
talks as if there is a single, yet-to-be created GUI. There is no
single concept of a GUI and we have been over this many times
to little avail.  But many of us think that a generic GUI
is of little research or even practical value. But we do
think customized interfaces, e.g. to interactive, dynamic
documents, is worthwhile.  Hence the differences. And hence
also the development of truly extensible toolkits, rather than
specific views of what a GUI would like.  It is great that
you want to focus on a particular group of potential users;
likewise for JGR, Rcmdr, etc.


Also, while R is a functional language which Duncan Murdoch
has mentioned in another mail and so is different from
other languages such as C/C++, Python, etc. that have been used
to develop GUIs,  the ability to have mutable state via closures
has not inhibited us in developing GUIs in R.  And the event
loop is not intrinsically different in these other languages
(except Java). It is just something that some of us have to agree on.


Enough for now.

 D.
Gabor Grothendieck wrote:
- --
Duncan Temple Lang                duncan at wald.ucdavis.edu
Department of Statistics          work:  (530) 752-4782
371 Kerr Hall                     fax:   (530) 752-7099
One Shields Ave.
University of California at Davis
Davis, CA 95616, USA
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDUZ4G9p/Jzwa2QP4RArL/AJ0c4AhBc2ma+SxW+iuU0vCVjUdcagCfYxOA
JIYlMXy0mxRp0ZnNKBbzayA=
=FwyB
-----END PGP SIGNATURE-----
James Wettenhall
# 
Hi Philippe and everyone else,

As you know, I have certainly spent some time thinking about R-GUIs, and
developing some R-Tcl/Tk GUIs - limmaGUI and affylmGUI (available from
Bioconductor).  I have also spent some time wishing we could use a GUI
toolkit with a more modern look and feel.  Hence I have investigated
wxWidgets, and thought that using wxPython might be the easiest way to
interface it from R, but I ran into some technical problems (especially
because I was obsessed with trying to make the interface from R to wx seem
not-too-object-oriented, i.e. I like the idea of 1. create a dialog, 2.
add a button etc. like in Tcl/Tk rather defining a dialog class, then
defining an object which is an instance of that class and then invoking a
show method on that object etc.)

I can't really afford to make R-GUIs much of a priority in my work any
more (so I may not read these philosophical discussions about which GUI
toolkit is best as closely as I used to), but I'm happy to answer any
specific questions about my experience with R-GUI development.  I hope
that doesn't sound too presumptuous of me, but I think that John Fox's
R-Tcl/Tk GUI package (Rcmdr) and mine (limmaGUI and affylmGUI) are some of
the most sophisticated (and most popular in terms of users) attempts to
build a platform-independent GUI interface to a command-line R package (or
packages).  And then there are other really nice GUIs for R which are not
necessarily platform independent - like some of Philippe's SciViews
software, and I recently came across a really nice GUI using GraphApp
(Windows only) for connecting to ODBC - I think it was in Brian Ripley's
RODBC package.

One point I wanted to make here is that there are some people in the R
community who have really great experience to offer from trying to develop
better R GUIs, but who don't necessarily participate on the R-SIG-GUI
mailing list.  For example, I was talking to Jan de Leeuw on the R-SIG-MAC
mailing list and he mentioned that he has done some great work trying to
interface R-wxPython, but that it was difficult maintaining the glue
between the different components.  And there are people in Bioconductor
(e.g. Jianhua Zhang - widgetTools & tkWidgets,  Jeff Gentry -
widgetInvoke) and there are people who have been involved in OmegaHat e.g.
Duncan Temple Lang who all have great experience to offer.

But some of the 'philosophical' ideas that people would like to implement
e.g. interfacing R and wxWidgets 'directly' without going through Python
(e.g. using Cable Swig) (or interfacing R and Tk via C rather than via
Tcl) seem like a massive task, and no-one seems sufficiently motivated to
provide money to employ someone (or multiple people) to do something as
big as that.

Just my thoughts.  Feel free to ignore.
Regards,
James
Philippe GROSJEAN
# 
Hello James, Duncan and the others,

There are interesting arguments in your posts. I think I must react to 
one of Duncan's considerations:

"Philippe, while you think that people are to individualistic in their 
development of GUIs, I think perhaps a better interpretation is that 
many of us are trying to develop GUIs quite different from what you have 
in mind.  Your mail talks as if there is a single, yet-to-be created 
GUI. There is no single concept of a GUI and we have been over this many 
times to little avail."

We probably have the same feeling about the large palette of possible 
GUIs (look at the page http://www.sciviews.org/_rgui/rgui/GUIs.html, 
that I wrote more than one year ago). However, my idea is effectively to 
make a single GUI, flexible enough to accomodate all situations and uses 
(do I need to add that it is *not* necessarily derived from SciViews, 
but it must certainly arise from a collaborative work between all people 
interested in the R-SIG-GUI list and others).

There are several functions shared by the various R GUIs, and recoding 
the same function again and again is really a waste of time. If you 
carefully look at JGR, SciViews-R and R Commander, you will see that the 
same main paradigm is used: a script editor in top of bottom of a 
console window, plus "helpers" to ease beginner's work (menus & dialog 
boxes, object explorer, etc... Again, not the only possible GUI, but one 
that proves useful in some situations). For instance, the object 
explorer has been coded at least three times (once in JGR, once in 
SciViews-R, and again, a more static and basic one in R -browseEnv() in 
utils package-). What a waste of time that would have been avoided if 
there was an "R Object Explorer API" available that everybody can reuse. 
This is where I see too much individualism: nobody, including myself, 
considered that the functions they wrote for the object explorer should 
be done and documented in a way they would be reusable by others 
(exception of browseEnv(), of course). I could cite countless examples here.

Where I am more surprised, it is when I proposed that idea of a reusable 
R GUI API one year ago, and started to write it, I found no echo at all 
in other developers. Nobody seems to be interested by the idea of 
reusable building blocks for R GUIs, although reusability is really the 
key of successful software development nowodays. Duncan, I am pretty 
sure you feel that all you did in OmegaHat is underused, probably for 
the same reason.

Other reasons why a good and fully-featured R GUI takes very long to 
develop in an Open Source context: the lack of programmers. Good R 
programmers, those who actually make R, are more interested by enhancing 
R itself than by writting a GUI for it, because they don't need a GUI 
and are pretty satisfied with the CLI and/or ESS. Other kinds of 
programmers wanting to participate in the development of Open Source 
software are more encline to participate to widely used software like 
Apache, Mozilla, OpenOffice, etc... than to dedicate their free time for 
programming a GUI for an obscure statistical software, with marginal use 
compared to the previously cited software. Finally, the only programmers 
really interested by a R GUI have very specific needs, like the use of R 
for teaching (John Fox, and myself, for instance)... and it happens that 
the very few people ready to dedicate a part of their free time to the 
development of a R GUI all act as individualists, starting their own 
project alone and with no or little reusability between GUIs projects in 
mind.

In such a context, the situation is pretty desperate. Open Source means 
software made by users for users... but in the particular case of R 
GUIs, users that need them (beginners), usually are those that *cannot* 
participate to their development, and the Open Source paradigm simply 
does not work as well for that particular reason.

That said, we are intelligent and proactive people. So, once the 
situation is analyzed, could we react in a positive way? Could we decide 
to put each piece of experience, materialized by several half-finished R 
GUIs (the current R GUIs that are considered as finished are indeed less 
ambitious projects, satisfied with a couple of basic features, which is 
the same result as more ambitious projects flagged as half-finished).

Some thinkings in this direction lead me to build a bridge between R 
Commander and SciViews-R, and in a near future, between Rpad and 
SciViews-R. Also, with Jose Claudio Faria, we are thinking on a 
reimplementation of Tinn-R in a platform-independent way, probably 
Java-based... a possible bridge with JGR is obvious here. These 
thinkings are summarized in a document: 
http://www.sciviews.org/EclipseAndR_Evaluation.pdf. Also, for what I 
tell about the idea of a R GUI API, one could read part II of the 
SciViews-R manual (http://www.sciviews.org/SciViews-R/Manual.pdf).

I am not much interested by endless discussions and considerations. I 
would rather like to feel a serious willingness in starting a 
collaborative work between all people that will read this email... and I 
am waiting for real actions going in this direction. As I said, I will 
have a couple of contracts in 2006-2007 where the development of a R GUI 
is part of the job, leaving me the opportunity to hire one or two 
developers on it. Whether these developers will continue the work on the 
current Windows-only SciViews-R, or on a more general project will 
largely depend on the echo I got in the R GUI developers sphere, 
regarding my suggestion of a reusable R GUI API and a polymorphic and 
full features R GUI as sketched in the two document cited hereabove.
Best regards,

Philippe Grosjean
James Wettenhall wrote:

        
Duncan Temple Lang wrote:

        
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


I think it is a little premature to entirely discount
Gtk2, especially if it is based on Philippe's remark
below.  Philippe, did you try other applications,
different themes, different configurations, or just the vanilla GIMP?
and when? While I don't necessarily disagree with the claim that it is
different from Windows look and feel, it requires a little bit more
evidence.

When I complete the SWIG module for R and the associated
more advanced tools, I may pursue an automatically
created interface to wxWidgets that would by-pass the
RSPython dependency.

Unfortunately, many people have become more vested in
Tcl and sub-optimal solutions because it is there.
We need to keep pushing infrastructural development and
what is feasible.  For some of us, the collection
of widgets and the possibilities that they introduce
are more important than cosmetic details, which of
course are important but won't necessarily advance
the paradigms of analysis.

Philippe, while you think that people are to individualistic
in their development of GUIs, I think perhaps a better
interpretation is that many of us are trying to develop
GUIs quite different from what you have in mind.  Your mail
talks as if there is a single, yet-to-be created GUI. There is no
single concept of a GUI and we have been over this many times
to little avail.  But many of us think that a generic GUI
is of little research or even practical value. But we do
think customized interfaces, e.g. to interactive, dynamic
documents, is worthwhile.  Hence the differences. And hence
also the development of truly extensible toolkits, rather than
specific views of what a GUI would like.  It is great that
you want to focus on a particular group of potential users;
likewise for JGR, Rcmdr, etc.


Also, while R is a functional language which Duncan Murdoch
has mentioned in another mail and so is different from
other languages such as C/C++, Python, etc. that have been used
to develop GUIs,  the ability to have mutable state via closures
has not inhibited us in developing GUIs in R.  And the event
loop is not intrinsically different in these other languages
(except Java). It is just something that some of us have to agree on.


Enough for now.

  D.

  
  


  


      

    

    

      
      

        


  

        

      Brian Ripley
    

    

      
      #
    

  


  

      
On Sat, 15 Oct 2005, Duncan Temple Lang wrote:

        

            

      
      
      
    

        
My main concern has been stability of gtk/gtk2 under Windows.  I've used 
it off and on for several years, and it has always been flaky -- sometimes 
it works on one computer but crashes on another, for example.

Personally, I have not seen any GTK2-based application that I find better 
than acceptable as a GUI, whereas I have seen some Qt-based ones I really 
liked.  But I realize this is a matter of individual taste (as it seems 
are Tk widgets - someone must like them!).

However, as an educator I see a lot of resistance to learning new tricks 
without good reason.  If the point of adding a GUI to R is to avoid people 
learning to use a command-line, it needs to be a GUI with which they are 
comfortable.  (I presume that is part of the reason why applications 
flocked to MS-Office style GUIs a few years ago.)  People (such as me) who 
are not comfortable with such styles are not in a good position to judge 
their needs.

[...]

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Dirk Eddelbuettel
    

    

      
      #
    

  


  

      
On 16 October 2005 at 14:04, Prof Brian Ripley wrote:

        
| whereas I have seen some Qt-based ones I really liked.  

Qt is C++, cross-platform using native widgets on OS X and Win and (since
more recently) available without fee or license woes provided it is used for
GPL'ed code.  

So it satisfies both the requirement to make it look and feel native
whereever possible, and satisfies the preference for an OO paradigm for GUI
programming.

Would it be an alternative?  Is it worth a prototype app?

Regards, Dirk

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Thomas Friedrichsmeier
    

    

      
      #
    

  


  

      
Hi,

            

      
      
      
    

        
If you seriously consider writing a Qt app, please have a look at RKWard (at 
least to find out, which portions of the code to reuse). RKWard is not a pure 
Qt app, however, but a KDE app. KDE 4 is promised to be cross-platform (but 
won't be released for another year or so), so I hope RKWard will be 
cross-platform, then.
Also, note that RKWard uses a somewhat different approach, than most other 
R-GUIs (as far as I know), in that _all_ the GUI stuff is done in C++-code 
(or plugins). There is no API to build GUI(-elements) from R in rkward, and I 
don't have plans to add that in the near future.
On the discussion iniated by Philippe: I don't think there will ever be a 
single united R GUI. It's not like this discussion has not come up before. I 
agree this has something to do with individualistic developers, and I'll 
admit to being one myself. But there are other reasons as well.
What I do believe, is that there could be collaboration in some areas. Years 
ago I proposed a standard for defining some GUI-elements. Philippe was pretty 
much the only person expressing interest at that time, but now uses an 
entirely different approach.
Another area could be drawing up a flexible output-format, and R-methods to 
create such output. R2HTML does a pretty good job, for the time being, but 
ultimately, we'll want an output format that does some more abstraction, for 
instance, to allow changing the number of digits to display on the fly, etc. 
If we could agree on a common standard for this, it could save all projects a 
lot of effort. (But no, I haven't worked out any specific ideas for this, 
yet).
I think you'll have a hard time, convincing any of the projects to give up 
their individualistic approaches (including any agreement, even on which 
programming language to use). All I can see is some projects might share some 
common standards.

Regards
Thomas

  
  


  


      

    

    

      
      

        


  

        

      Philippe GROSJEAN
    

    

      
      #
    

  


  

      
Thomas Friedrichsmeier wrote:

            

      
      
      
    

        
I suspect you are more interested by the challenge of making a R GUI 
than of having that GUI fully operational for everyday work. People like 
me *do need* a fully-featured R GUI for their everyday work... and miss 
it! I spend countless hours to achieve this goal, and I ultimately 
arrive to the conclusion that the entreprise is huge, and it is very 
difficult to reach the goal for a single person that dedicate a little 
bit of its free time to such a project. So, yes, I am ready to give up 
SciViews and all my convictions to work *collectively* on a common R GUI 
project. I hope there are other people out there that are more 
interested by the result than by the fun of starting and managing yet 
another project on their own,... and that they progressively arrive to 
the same conclusion: we need to harness several programmers on the same 
project to have any chance to finish a really full-featured R GUI in a 
reasonable amount of time.

Another problem, for a slowly moving project like SciViews-R is the fast 
evolution of R itself. It means that almost all the available time is 
spend making changes just to keep the GUI compatible with the latest R 
version, leaving very little time for programming new features and for 
writting the documentation.

I took a look at Qt a few times, and I was always stopped by the 
commercial license (at least under Windows). I just visit Qt web site. 
Yes, indeed, there is a GPL license now. Very good news!

Best,

Philippe Grosjean

  
  


  


      

    

    

      
      

        


  

        

      Marc Schwartz
    

    

      
      #
    

  


  

      
Greetings all,

While recognizing that "this is easier said, than done", is there any
logic in suggesting that for those who might be interested, a specific R
GUI session of sorts be added to the UseR! 2006 meeting schedule?

Since some quorum of interested GUI users may be planning to attend the
meeting or may be motivated to do so, it may be an opportunity to:

1. Leverage face to face interaction and visualize possible options

2. Define areas of commonality

3. Bring some level of focus to targeted segments of the user base that
would utilize a GUI and for whom there may be differing functional
requirements.

4. Identify cross-platform opportunities and technologies

5. See further notes below...


Some of the preliminary work could no doubt be done in advance to better
prepare and structure discussion.

This could be done as a "breakout" session or if there is sufficient
interest (and facility/funding issues can be resolved) perhaps a group
session held the day before or perhaps the day after the main conference
program.

If there is a core group that is interested in pursuing this, an
announcement could be made to the respective R e-mail lists (r-help,
r-devel, r-sig-gui, etc.) whereby, with the sufficient lead time as we
have, the requisite activities could be put in place to orchestrate the
session, define specific desired outcomes and identify individuals
willing to spend their time to coordinate and make this venture
successful (however success would be defined).

There is no business or financial motivation here for a GUI. If there
was and a for profit company decided that there would be a significant
return on investment, they would spend the money, hire the resources,
define a team leader and put forth a single development spec for a GUI
project based upon their own market research. It would be done in a
relatively authoritarian fashion and if you didn't agree, you would be
asked to find a job elsewhere.

Here, you would need to solicit voluntary resources, reconcile the
expected differences of opinion on the spectrum of matters that would
have to be addressed and define some common framework for operating,
perhaps based upon targeted user segments.

This subject, as mentioned, has come up on the lists previously, with no
common resolution, resulting of course in the individual activities that
have emerged.

Is there a group of motivated useRs out there, who have the time,
energy, and skills and are willing to work within the framework of a
design and development "team" environment, where a quid pro quo for
moving forward could evolve from the User! 2006 meeting? 

Is there an individual, who would need to emerge from that group, who
has the respect and requisite skills to drive a consensus of opinion and
keep a team focused and moving in the proper direction?

If so, that might be a step in the direction of evolving a GUI that
might make sense for some yet to be defined range of useRs, who would
not otherwise utilize the CLI or might need to evolve in that direction
over time.

If not, then the status quo continues...

There are some 300 Linux distributions out there and multiple X based
GUIs, which have evolved for reasons as varied as those behind the
available R GUIs and more. Yet there are a select few base Linux
distributions and largely two GUIs that have garnered any significant
market share. Perhaps, over time, lacking any coordinated activity, a
similar situation will evolve here, if the predicate that a broad demand
for a R GUI is valid.

If the predicate is false, then this process is perhaps rightly done by
individuals meeting narrowly focused, local requirements.

I should note, that I am not prospective GUI user, but a happy ESS user.
I simply thought that I would try to provoke some discussion on this
point, since I jumped into this thread earlier in the week.

Best regards,

Marc Schwartz

  
  


  


      

    

    

      
      

        


  

        

      A.J. Rossini
    

    

      
      #
    

  


  

      
Interesting.

So, we've got lots of people that want GUIs, lots of variants with
existing prototypes, and lots of clamor for skilled collaborators.

As most of the work has seemed to be of the "I know this, and this is
what I want to do", it will be interesting to see how it shakes out. 
I've still not seen a GUI that I'd call good.  There are many adequate
ones, and I've finally reached the point of appreciating the adequacy
of the MS approach (which is different than my previous attitude).

I hope someone creates a good one that is stable.  That's half the
problem right there, in that the implementation is a huge component of
the theory.

Widget sets are less interesting than the overall approach, but
unfortunately provide the basic characterizations of what might be
possible.

best,
-tony

blindglobe at gmail.com
Muttenz, Switzerland.
"Commit early,commit often, and commit in a repository from which we can easily
roll-back your mistakes" (AJR, 4Jan05).

  
  


  


      

    

    

      
      

        


  

        

      Dan Putler
    

    

      
      #
    

  


  

      
Hi All,

While I don't have the "sweat equity" that either Philippe Grosjean  
and James Wettenhall have in developing R GUI's, I have been involved  
in two different projects (obveRsive as part of the founding  
development team, and R Commander as a contributor) over the past  
three years. In addition, my interest is in R GUIs that are not  
platform specific (such as Philippe's SciViews for Windows or Thomas  
Friedrichsmeier's RKward for KDE). Based on a combination of both my  
experience and my interest, I want to make two observations, and  
offer three opinions about issues people should consider when  
thinking about what they can do to move GUI's for R forward.

My first observation is that gluing R to any external, platform  
independent, widget tool kit is hard. James indicates that it isn't  
easy for wxWidgets. My memory is he got it to work under Window's,  
but had a hard time making it work under Linux, and Jan de Leeuw also  
found it to be a real challenge just to get the RSPython layer to  
work under Mac OS X. On the obveRsive project we decided to use the  
Fox tool kit because (1) it had a larger selection of more "modern"  
widgets compared to Tk, and (2) it was the only multi-platform  
toolkit that actually worked under Windows, Linux, and Mac OS X  
platforms at the time we started the project in late 2002 (at that  
time wxWindows hadn't actually been ported to OS X). In order to use  
the Fox toolkit, we decided to use R as a backend. However, we, along  
with a number of other failed early projects (we pretty much decided  
to admit the demise of obveRsive this past week), found this to be a  
Herculean task (Zed Shaw in his work on obveRsive spent many  
frustrating nights trying to think of ways to develop a backend  
approach that worked quickly and consistently). Ultimately, R does  
not behave the way Perl, Python, Ruby, and Tcl/Tk do, which makes  
gluing it to an external GUI toolkit a real chore.

The second observation is that the R Tcl/Tk package is incredibly  
robust (the efforts of Peter Dalgaard and others who have worked on  
this effort should really be applauded in my opinion). I've used  
Rcmdr (based on the R Tcl/Tk package) successfully in classes where  
students used a mix of Windows and Mac OS X machines. To be honest,  
that it works at all, let alone that it is so rock solid, under Mac  
OS X simply amazes me since the Tcl/TK widgets use a different  
windowing system (X11) than the R console application (run under  
Aqua) in a standard, CRAN based, setup on OS X.

My first opinion is that too much bandwidth on the R-sig-gui mailing  
list has been spent on philosophical arguments about which toolkit is  
the "right" one to use. From a practical perspective, the Tk toolkit  
works well on all major platforms. The only real potential  
alternative for multi-platform application seems to be Java (as  
Philippe indicates, GTK2 is problematic under Windows, but also has  
some issues under OS X). However, only the JGR project appears to be  
using Java for an ambitious multi-platform application. At this  
point, I would really like to hear Markus Helbig's, Simon Urbanek's,  
Martin Theus's, and other JGR developers' opinions about the  
suitability of Java as a general tool for developing GUI's for R  
since they would have well informed opinions on this topic.

Second, it is my belief that there is a huge potential benefit to  
devoting efforts to simplify the use of the available working tool  
kits (i.e., the R Tcl/Tk package and Java) so that it is easier to  
develop GUI dialogs for a package or a specific procedure. To that  
end, John Fox has developed a number of macro-based "helper  
functions" for Rcmdr that greatly simplifies the creation of GUI  
dialogs for this package. My guess is that some of these could be  
fairly easily included as part of the R Tcl/Tk package. Moreover,  
other helper functions, based on John's approach, could also be  
developed. Going a bit further, as part of the obveRsive project,  
Thomas Friedrichsmeier wrote a module that enabled obveRsive dialog  
writers to write their dialogs using xml tags. His xml tags approach  
really simplified dialog creation. However, porting what he did for  
obveRsive to R Tcl/Tk would be a very difficult task, but one that is  
worth considering.

  My final opinion (which is focused on the R Tcl/Tk package) is that  
having a limited and "ugly," but working, set of widgets is much more  
important than having an extensive collection of "modern" widgets  
that behave badly, or are only available for some OSs. This is not to  
say that I think no effort should be devoted to expanding the set of  
widgets available under the R Tcl/Tk package, rather, I think there  
is a need for a conversation and consensus about which additional  
widgets would likely provide the greatest improvement in GUI  
applications developed under R as a way of prioritizing any efforts  
in this area, and that the goal of these efforts should be to make  
the desired widgets available under all major operating systems on  
which R runs.

Overall, my belief is that R already has a number of useful tools for  
developing GUIs, and that there is probably much greater return to  
efforts to improve the usability of these existing tools than in  
developing completely new toolkits or developing an API from scratch  
as this moment in time.

My apologies for the length of this post.

Dan

        
On 15-Oct-05, at 8:27 PM, James Wettenhall wrote:

        

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Hin-Tak Leung
    

    

      
      #
    

  


  

      
Hi,

Since you mentioned tcltk2 and python+wxWidgets, what about Tkinter 
(python's built-in binding to tk)? It is somewhere between the two,
and is shipped as standard these days with python 2.x. Also, if Perl/Tk
works, and Tkinter works, there is no reason why one can't do R/Tk,
without the Tcl (or the obvious Tcl-ish stuff) in the middle.

Just an idea.

Hin-Tak Leung

        
Philippe Grosjean wrote:

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Philippe GROSJEAN
    

    

      
      #
    

  


  

      
Hello Marc and the others (and the User!2006 organizing commitee),

I answer to Marc's email, because I think it is the most constructive 
one. I am a little bit dissapointed that the discussion about R GUIs, 
whatever the initial subject, inevitably shifts to an endless discussion 
about which graphical toolkit to use, and whether one should interface 
it directly, or by means of an intermediary language perhaps more 
suitable for handling widgets events.

Should I recall that this thread is *not* about which graphical toolkit 
to use, but is trying to trigger a discussion on how could we work 
together to avoid duplication in coding for R GUIs, and perhaps, join in 
a common project. Something totally different!

I know people that already play the game of collaboration: those I am 
working with to bring bridges between their projects and SciViews-R. 
There is another person working on general improvements of R for GUIs: 
Duncan Murdoch, but this is about RGui.exe, thus for Windows only.

I support the proposition of Marc Schwartz to dedicate a session in 
User!2006 to this subject... but I would like to precise this: it should 
be stated clearly that the GUI session would *not* be about discussing 
which graphical widgets to use, and *not* on the presentation of yet 
another new R GUI project. That session should be clearly focused on:
- actual examples of use of R GUIs, and the benefit their bring in practice,
- propositions for developping a common and reusable API for R GUIs 
(preferrably written in R to be independent of particular graphical 
widgets -I started such a thing in svDialogs, and I think that Simon 
Urbanek's Iwidgets is similar in philosophy-),
- bringing bridges between existing R GUI projects,
- identifying cross-platform opportunities.
That session should be followed by an extensive discussion (why not 
around a drink, or a good meal?), between interested people. The 
discussion should be best focused on:

1) How and who will install tools for collaborative work on those common 
R GUI pieces of code (a CVS or SVN for instance)... we already have a 
web site and the R-SIG-GUI, even if these tools are currently under-used.

2) How and who will sketch documents summarizing our goals. Of course, 
these documents should be editable by everybody. So, something like a 
WiKi sounds good here.

3) In a near future, we will begin to add code in the "common R GUI 
tools", of course. This should be pieces of code extracted from the 
various R GUI projects. So, we have to draw an initial list of these 
pieces of code and who will provide them.

I CC: this mail directly to the User!2006 organizing committee, because 
it is a direct call asking for such a session. Regarding the organizer, 
  I wouldn't propose names... someone from the R developer's team, or a 
key person in R GUIs topics...
Best,

Philippe Grosjean

..............................................<?}))><........
  ) ) ) ) )
( ( ( ( (    Prof. Philippe Grosjean
  ) ) ) ) )
( ( ( ( (    Numerical Ecology of Aquatic Systems
  ) ) ) ) )   Mons-Hainaut University, Pentagone (3D08)
( ( ( ( (    Academie Universitaire Wallonie-Bruxelles
  ) ) ) ) )   8, av du Champ de Mars, 7000 Mons, Belgium
( ( ( ( (
  ) ) ) ) )   phone: + 32.65.37.34.97, fax: + 32.65.37.30.54
( ( ( ( (    email: Philippe.Grosjean at umh.ac.be
  ) ) ) ) )
( ( ( ( (    web:   http://www.umh.ac.be/~econum
  ) ) ) ) )          http://www.sciviews.org
( ( ( ( (
..............................................................

        
Marc Schwartz wrote:

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Thomas Friedrichsmeier
    

    

      
      #
    

  


  

      
Hi Philippe,

            

      
      
      
    

        
ok, I misunderstood you then. I thought you were in fact talking about drawing 
up a common ultimate R GUI project. Then in fact, discussions about which 
toolkit to use, etc., would arise quite naturally. And that is, what I wrote 
in my last mail, what I don't think will ever lead anywhere.
If you're talking about finding certain defined areas of collaboration, I'm 
all for doing that. I don't think I will attend UseR, but I'm certainly open 
to discussions of this sort. I support the idea of a wiki.
Here are some thoughts, on what I think might be areas of collaboration:

1) You talk about an API for R GUIs written in R. To me personally, this is 
not an attractive topic, as my approach is to do _all_ GUI stuff outside of R 
(I think of R more as an evaluation backend in rkward). Of course this is no 
reason against starting such a discussion. However, in addition, I'd like to 
bring in my idea of xml-specified GUIs again (this is useful in my approach, 
but probably not so much in yours). This could be discussed as a _separate_ 
topic.
2) As I mentioned in the last mail: Drawing up a flexible output format, that 
will allow small modifications on the fly. This includes R functions to 
generate such an output format. Something like R2HTML, only more flexible, 
allowing for dynamic changes.
3) R library API enhancements. GUIs have some specific needs for the R 
(C/library) API. Such needs do not seem top priority for the R core 
developers (no offence intended). Last week I proposed some API additions to 
the R C API on r-devel, but never received a reply. I have several more items 
in mind that I would like to see added/changed in the main R library. 
Probably it would be good to have some collaboration on identifying, and 
elaborating our C-API needs.

Many more areas of collaboration could probably be identified. However, I'd 
strongly advise to keep such topics small, well defined, and separate from 
each other. Otherwise we'll once again end up in the discussion about the 
great merger of all R GUI projects, which I don't think will lead anywhere.

Regards
Thomas

  
  


  


      

    

    

      
      

        


  

        

      John Fox
    

    

      
      #
    

  


  

      
Dear Marc et al.,

As the author of an R GUI, I've been following this thread with
interest. 

I think that both a session at the UseR! conference and a more informal
meeting to provide an opportunity for discussion are a great idea. It's
hard to make much progress on this kind of issue via email discussion
because there doesn't seem to be general agreement on what is
problematic. For example, some of this thread has focused on the
provision of a tools for R GUI construction, while some has focused on
the relative merits of different GUI toolkits and how to make them
available in R.

Regards,
 John

On Sun, 16 Oct 2005 14:21:25 -0500

        
Marc Schwartz <MSchwartz at mn.rr.com> wrote:

            

      
      
      
    

        

      
      
    

        
--------------------------------
John Fox
Department of Sociology
McMaster University
Hamilton, Ontario, Canada
http://socserv.mcmaster.ca/jfox/

  
  


  


      

    

    

      
      

        
      

    

    

      
      

        


  

        

      James Wettenhall
    

    

      
      #
    

  


  

      
Hi,

One point I forgot to make last time is that I'm a big fan of prototyping.
 I have almost no experience whatsoever in Java Swing, but there are
plenty of people in the R community who do - e.g. Simon Urbanek and the
JGR team.  In the past, I have had trouble finding any elegant prototypes
(e.g. "Hello, World" applications) interfacing R with Java Swing.

Similarly, I'd love to see "Hello, World" prototypes for R-Qt etc. Of
course for many of those GUI systems originally developed for Linux or
Unix, there is the question of how reliably you can port them to the most
popular operating system in the world and to MacOS X.  I love using GIMP
under Windows, but how many Windows software developers would say that
compiling GTK on Windows (e.g. within an R package) is easy?  That's why I
liked wxPython/wxWidgets because it didn't attempt the difficult task of
porting GTK to Windows - it just uses native Windows widgets on Windows
and GTK widgets on Linux.

I don't want to emphasize my interest in prototypes too strongly though -
I still think that there is a lot of work to be done beyond any prototype.
 Maybe the successful publication of Rcmdr in the Journal of Statistical
Software will give me hope that the academic community will eventually
feel more comfortable asking for money to employ people to do some
challenging GUI-related software development which may not immediately
promise publications within the core research aims of a particular
department/institute.   Or maybe [horrible thought], some business outside
the academic community will provide a very expensive but very good GUI
development system for R.

Best regards,
James

  
  


  


      

    

    

      
      

        


  

        

      Peter Dalgaard
    

    

      
      #
    

  


  

      
Hin-Tak Leung <hin-tak.leung at cimr.cam.ac.uk> writes:

            

      
      
      
    

        
As far as I know, Tkinter does use Tcl as a glue language, just like
R. Perl/Tk tried the stunt of bypassing Tcl, which I think mainly has
bought them difficulties in keeping up with new Tk versions. Notice
that a direct Tk interface needs to map each and every piece of Tk
functionality, whereas you otherwise just need to implement tcl() and
a handful of object conversion routines. (OK, so it wasn't all _that_
simple, but you get the point...)

The Tcl C interface that gets used by the tcltk package is actually
one of the strong points of Tcl/Tk (as opposed to Tcl as a scripting
language for entire applications, which can be a bit of a pain.)
Especially with the Tcl_EvalObjv interface in place, things really
work quite smoothly, since the "quoting hell" of the string-based
interface is bypassed.

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Duncan Temple Lang
    

    

      
      #
    

  


  

      
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

        
Philippe Grosjean wrote:

            

      
      
      
    

        
I think all of us will agree that we have limited resources
and should collaborate where possible.
However, to do this, we must have a common set of interests
that form a reason to collaborate.
Your earlier mail mentioned the link
(http://www.sciviews.org/_rgui/rgui/GUIs.html)
to the different types of GUIs you were considering, be it
a Web-based, or notebook style, or whatever.

I really think that you have to think about things from other peoples'
perspectives and realize that many of us are not considering "the GUI"
as you are. You seem to have an audience in mind which
  a) need access to a broad range of R functions
  b) are averse to the command line.
It appears you have students in mind, probably non-statisticians
in an introductory class.  That is great. And your approach is
perfectly reasonable to address that need.

However, others of us have very different goals.
Some of us want specialized GUIs, e.g. GeneGGobi, interfaces
to specific functionality (e.g. random forests), ....
Others of us have been buidling tools for interactive documents, much
like a Web browser embedded in R with complex composite widgets
embedded within the document to have dynamic, interactive documents.
These are very different audiences, and accordingly very different
GUIs.  They require not customization of a general GUI, but
an ability to construct entirely new GUIs.

Where we can really collaborate is in the development of
GUI components that can be used from within R to construct
these different GUIs.

I really encourage you to try to consider what other people
are thinking and hopefully this will help us get past the
discussions of specific toolkits, etc.  I think they have
originated from beliefs that we are all talking about variations
of the same student-oriented GUI. In fact, we are talking about
much richer forms of pedagogy and interface.

 D.

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

        
- --
Duncan Temple Lang                duncan at wald.ucdavis.edu
Department of Statistics          work:  (530) 752-4782
371 Kerr Hall                     fax:   (530) 752-7099
One Shields Ave.
University of California at Davis
Davis, CA 95616, USA
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDU9h19p/Jzwa2QP4RAmYjAJ992GZhsa2XXu+RgC2ma7WlnmfvJQCeK1AS
nf7SVZeZsoS4Q9gaigI6U8c=
=r1zP
-----END PGP SIGNATURE-----

  
  


  


      

    

    

      
      

        


  

        

      Philippe GROSJEAN
    

    

      
      #
    

  


  

      
Duncan,

Could you, please, stop considering me as just a professor in 
biostatistics only interested by the results of my students and nothing 
else. Do you need a couple of evidences that I am working with other 
people, other applications, and that they require totally different 
GUIs? Here they are:

1) I am the instigator and main programmer of ZooImage 
(http://www.sciviews.org/zooimage/), an Open Source system combining 
ImageJ and R (mainly) to provide a complete numerical image analysis 
system for automating zooplankton samples processing. In the R side, 
image measurements gathered by ImageJ are analyzed with the powerfull 
machine learning algorithms implemented in R (like random forest, 
bundling, ...). After analysis of several samples, they usually form a 
space or time series to be analyzed by respective tools, still in R. 
Targetted users are biological oceanographers... most of them are 
reluctant to "programming" in R (i.e., to write and edit little scripts 
to run the analyses), and the others are more accustomished to Matlab.

2) I participate to the development of FLR (http://flr-project.org/), a 
framework for modelling fisheries entirely written with S4 objects. The 
project is now used in several fisheries evaluation programs, and we 
face some problems with modellers and advisors telling they don't want 
to have to "learn R" for running their models. Quite different 
application and targetted users.

3) One of the future contracts I mentioned earlier in this post is with 
IFREMER, to make a flexible reporting system mixing the report() 
functions of SciViews and Rpad to end up with dynamically recalculable 
HTML reports (hopefully web-based solution), for instance for weekly 
reports on the survey of water quality along the French coast. Again, a 
very different application and GUI.

4) Another contract consists in making an artificial human noise, 
analysing results from more than 200 artificial odor receptors. The 
people there agree for using R as the "calculation engine", but want a 
really simple point and click interface for their analyses, and all the 
machinery completely hidden.

That said, if you consider a polymorphic R GUI that mixes together the 
different paradigms (menu&dialog boxes, spreadsheet, notebook-like 
interactive documents, ...) is not something possible to do, it is your 
problem. My own experience, *including the various different situations 
cited here above* make me feel that it is something possible. I don't 
want to kill all R GUIs projects in favor of a single one, but I affirm 
that we should work in a more collaborative way.

Best regards,

Philippe

..............................................<?}))><........
  ) ) ) ) )
( ( ( ( (    Prof. Philippe Grosjean
  ) ) ) ) )
( ( ( ( (    Numerical Ecology of Aquatic Systems
  ) ) ) ) )   Mons-Hainaut University, Pentagone (3D08)
( ( ( ( (    Academie Universitaire Wallonie-Bruxelles
  ) ) ) ) )   8, av du Champ de Mars, 7000 Mons, Belgium
( ( ( ( (
  ) ) ) ) )   phone: + 32.65.37.34.97, fax: + 32.65.37.30.54
( ( ( ( (    email: Philippe.Grosjean at umh.ac.be
  ) ) ) ) )
( ( ( ( (    web:   http://www.umh.ac.be/~econum
  ) ) ) ) )          http://www.sciviews.org
( ( ( ( (
..............................................................

        
Duncan Temple Lang wrote:

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Duncan Temple Lang
    

    

      
      #
    

  


  

      
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hi Philippe.

 I am sorry that you are upset by what I wrote.
I did not intend to cause offense.  And I was
not considering you as "just a professor only interested
by the results of your students".  However,
the discussion has unfortunately degenerated to that
common denominator for several people, either implicitly
or explicitly and I believe it is important to make
certain that the real issues are identified and discussed
by being precise about what it is that is being discussed.

I most certainly do thing a "polymorphic" GUI
that mixes different components is feasible.
Indeed,  I have been working on the integration
in general terms for many years and have developed
a general infrastructure for integrating such tools
in various settings.  What we are discussing is
the software architecture for constructing this
distinctly focused GUIs.

I think experiments in GUI design are terrific and
we need them.  I applaud SciViews for this.
And JGR, etc. too. But they don't necessarily
allow others to experiment as they are not
customizable. Just as users don't necessarily
want to learn R to do statistics, R programmers
don't necessarily want to learn Java or C++
and the specifics of an application like
SciViews or JGR to try out small changes.
That is why I have long argued that we use
the existing common interest that we all have
which is R and that we allow people
to reuse components of SciViews, etc.

If these are integrated into R so that people can
really modify them and construct different GUIS
from their elements, that would be terrific.
In the meantime, the ability to easily and conveniently
do experiments in R does warrant discussing a software
architecture that facilitates that and so involves
bindings to toolkits, both modern ones and convenient ones.

 Anyway, apologies again for the misunderstanding. I was
not considering you in that narrow fashion that came
across in my mail.

 Enough said for the moment. All these experiments are good,
collaboration is good. The obvious place to do it in my book
is in the R language or else have some good glue between the
systems.  As much work as I have done on GUIs in the S language
in  the last 13 years, I still think we need more glue and
am working on that while we continue to experiment with the
design of GUIs for the next 5 years rather than the immediate needs.


 Thanks,
  D

        
Philippe Grosjean wrote:

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        
- --
Duncan Temple Lang                duncan at wald.ucdavis.edu
Department of Statistics          work:  (530) 752-4782
371 Kerr Hall                     fax:   (530) 752-7099
One Shields Ave.
University of California at Davis
Davis, CA 95616, USA
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDU+ta9p/Jzwa2QP4RAnppAJ9dv+LRlZttkmI8epiPrkU3aUsNjgCeIhGD
5bD+9bu3xIy6Oioy3a63JNo=
=s0yj
-----END PGP SIGNATURE-----