[Rd] [R-gui] R GUI considerations (was: R, Wine, and multi-threadedness)
Duncan Temple Lang
duncan at wald.ucdavis.edu
Sun Oct 16 02:25:43 CEST 2005
-----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:
> 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
>>
>
>
> _______________________________________________
> R-SIG-GUI mailing list
> R-SIG-GUI at stat.math.ethz.ch
> https://stat.ethz.ch/mailman/listinfo/r-sig-gui
- --
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-----
More information about the R-devel
mailing list