R devel - Oct 2005 - 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 at umh.ac.be
  ) ) ) ) )
( ( ( ( (    web:   http://www.umh.ac.be/~econum
  ) ) ) ) )          http://www.sciviews.org
( ( ( ( (
..............................................................

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:
> 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
> ( ( ( ( (
> ..............................................................
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

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

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:
> 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
> ( ( ( ( (
> ..............................................................
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

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

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

If you're looking for a GUI toolkit that:

   1.  Is cross-platform,
   2.  Has a good collection of widgets that look good on all platforms, and
   3.  Is easy to work with from R

then it is hopeless.  There is no such toolkit.

As one poster mentioned, most of the better GUI toolkits are very
object-oriented, because that paradigm is a good fit for GUI programming. 
There are a few programming environments out there that do have nice GUI
abilities, but they all use base languages that are not very R-like, and so
the potential R GUI programmer is faced with having to use two very different
languages for his creation.  And even if that obstacle is surmounted, there
remains the difficulty of trying to package up his work in such a way as to
make it easily installed by others.  Things are always breaking in the
interfaces between R and whatever you're using.  Trying to keep it all
running
and packaging it for deployment are thankless, gargantuan tasks.

There is a better way, and that is to give up on R.  Start over with
a better programming environment, one that is object oriented, as flexible and
dynamic as R, is cross platform, easy to program in, and has decent GUI
facilities already.  Then port the stuff in R that does statistical
programming, and you have the best of all worlds. 

The environment I am thinking about is VisualWorks Smalltalk, which is free
for noncommercial use.  As a language, Smalltalk is both simpler and more 
powerful than R, and the VM it runs on is much faster than the R interpreter.
It has superior garbage collection and the best IDE in the business.
Callouts to C are just as easy as they are in R, but would likely not be
needed as often due to the faster VM and much better programming facilities.
Interfaces to various databases are possible, and the most powerful web
toolkit (Seaside) is written in Smalltalk and runs under VisualWorks.

There are a couple of other Smalltalk environments around that could also be
considered.  Squeak is an open source cross-platform Smalltalk that is not as
fast as VisualWorks, but still must faster and more robust than the R
interpreter.  Smalltalk/X is another possibility, though it works only on
Windows and Unix. 

Think about it.  Once you have a basic math package that can handle matrix
programming and various mathematical functions, building the various
statistical modeling tools on top of them is not that hard.  What makes S and
R so much better than SAS is their programmability.  Smalltalk is like that,
only better.


Jeff Hallman