For example, there is a need in proteomics for a  special-purpose 
proteomics-based statistical graphics engine and GUI.   In this context, 
for example, over this past year SAS has released a special-purpose 
plotting engine built on top of their JMP system,  that I believe is very 
good.  One would apt to want to write an analogous module in R.

In that context, may I note that in the past I have found CORBA to be a 
stodgy, heavy-footprint but also a reliable and high-performance way for 
putting Java,  Tcl/Tk and other GUIs on top of C/C++ analysis code.  So, 
my own suggested solution was to spend 1-3 months implementing a lean-mean 
TAO "ORB" implementation of the OmegaHat CORBA layer for R.  ( TAO is an 
open source ORB ).  I believed that this would simplify development and 
use of all different kinds of GUIs on top of R ( using some CORBA IDL in 
the process. )    However, my own solution could not be adopted because 
funding agencies and others in computing today prefer technology that is 
purely at the intersection of Java and gridified web services.  I am 
afraid that I am continuing to find out that this continues to be the 
case, that is, CORBA is regarded as a technology that is superceded by 
current and/or future approaches using the pair of technologies just 
mentioned.  However, a personal opinion is that the approach of CORBA and 
CORBA IDL ( stodgy and heavy-footprint as it is ) does still represent one 
useful way to greatly reducing the number of lines of code needed for GUIs 
written on top of "R". 

Overall, of course, whether or not CORBA option is chosen and  *funded* a 
way to attempt to simplify GUI-based solutions, obviously,  the topic of 
GUIs is obvously a crucial one, not just for "omics" work, but for other 
application areas as well.

Rich Haney
Richard.Haney@duke.edu
Duke Comprehensive Cancer Center







Philippe Grosjean <phgrosjean@sciviews.org> 
Sent by: r-sig-gui-bounces@stat.math.ethz.ch
10/15/2005 08:50 AM

To
r-devel@stat.math.ethz.ch, r-sig-gui@stat.math.ethz.ch
cc

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






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@umh.ac.be
  ) ) ) ) )
( ( ( ( (    web:   http://www.umh.ac.be/~econum
  ) ) ) ) )          http://www.sciviews.org
( ( ( ( (
..............................................................

_______________________________________________
R-SIG-GUI mailing list
R-SIG-GUI@stat.math.ethz.ch
https://stat.ethz.ch/mailman/listinfo/r-sig-gui


	[[alternative HTML version deleted]]

