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

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