From p.dalgaard at biostat.ku.dk  Mon Oct 17 17:09:12 2005
From: p.dalgaard at biostat.ku.dk (Peter Dalgaard)
Date: 17 Oct 2005 17:09:12 +0200
Subject: [Rd] [R-gui]  R GUI considerations (was: R, Wine,
	and multi-threadedness)
In-Reply-To: <435364AA.7000303@cimr.cam.ac.uk>
References: <4350FB09.3020503@sciviews.org> <435364AA.7000303@cimr.cam.ac.uk>
Message-ID: <x2irvwtc2v.fsf@turmalin.kubism.ku.dk>

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

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

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.
 
> 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
> 
> _______________________________________________
> R-SIG-GUI mailing list
> R-SIG-GUI at stat.math.ethz.ch
> https://stat.ethz.ch/mailman/listinfo/r-sig-gui
> 

-- 
   O__  ---- Peter Dalgaard             ?ster Farimagsgade 5, Entr.B
  c/ /'_ --- Dept. of Biostatistics     PO Box 2099, 1014 Cph. K
 (*) \(*) -- University of Copenhagen   Denmark          Ph:  (+45) 35327918
~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk)                  FAX: (+45) 35327907



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