[R-gui] Platform-independent GUI for R... again

[A.J. Rossini]

Good points all, and I'm in general agreement with most of your
points.  I'll be looking at this again in mid December, probably;
mostly due to resource issues.

best,
-tony


On Thu, 11 Nov 2004 12:53:43 +0100, Philippe Grosjean
<phgrosjean at sciviews.org> wrote:
> A.J. Rossini wrote:
> > I'm quite stalled on work until I settle into a permanent
> > flat in late december  (I just relocated to Basel,
> > Switzerland), but at that point I'll have a bit of time to
> > finish up some of the IDE work that I've coded bits and pieces for.
> 
> Good! As I previously said, I intend to design the R GUI API in a way it
> could be reused among GUI clients, and on all platforms supported by R
> itself. I want to make sure you will find there functions that will help you
> to add some GUI features to Emacs-ESS. I think you should look, among
> others, at svDialogs (dialog boxes), the various guiObjXXX functions in
> svGUI (to implement an object explorer), and the view/report methods in
> svViews. I am currently working on a manual that explains how all these
> functions work, and how they can be used to help implementing GUI features
> for R.
> 
> Regarding the rest of the discussion, with various suggestions in favor of
> such or such graphical toolkit done by other people, I think I have to
> mention that the R GUI API is made in a way it is also independent from a
> particular graphical toolkit. In svDialogs, dialog boxes can be build using
> different graphical toolkits very easily and remain compatible with one
> other. As an example, I have dialog boxes build with tcltk, and the same
> ones build using R-wxPython (but this can be done with little effort using
> Gtk, KDE, etc... too, as soon as they are accessible from withing R!). With
> svDialogs, it is the end user that ultimately decides which graphical
> toolkit he prefers to use, not the programmer. The end user does so simply
> by specifying 'options(guiWidgets = "XXX")', where "XXX" could be "tcltk" or
> "wxPython" (currently), but also "Gtk", "Qt", "Fox" or whatever in the
> future... (see page 98 of the manual: 'toolkit-independent API and toolkit
> implementations', at ftp://ftp.umh.ac.be/pub/ftp_econum/Manual.pdf). In case
> a particular dialog box is not implemented in the choosen graphical toolkit,
> the program switches back automatically to the default one, defined using
> the plain 'tcltk' package only. Here we just need volunteers to implement
> toolkit-specific features of these dialog boxes.
> 
> Well, I would say to conclude this little discussion that nobody really
> catches my request about a platform-independent solution for the GUI
> clients... It is not just menus and dialog boxes, it is something more
> complex, as SciViews R Console is... but only for Windows currently. It
> needs very sophisticated widgets, like a HTML browser widget CSS and
> javascript capabilities, an advanced code editor widget like Scintilla,
> etc...  These can be found in different places, but considering the coding
> difficulties, I am not yet convinced to switch to a different
> language/graphical toolkit/IDE than the ones I currently use. I think it is
> still too soon to move to another solution for that particular GUI client. I
> realize that the best I have to do is to continue its development until
> version 1.0 as it stands (i.e., a Windows-only solution), but to prepare the
> future and to devote more time and energy in buiding the
> platform-independent R GUI API, and as the utmost priority, to document,
> promote and collaborate with everybody wanting to discover or use the R GUI
> API I am setting up.
> 
> The various topics I am willing to offer collaboration with the R GUI API
> are:
> 1) help to further develop, debug and enhance the R GUI API itself, of
> course. In particular, I would be particularly happy with any initiative to
> implement dialog boxes proposed in svDialogs for various other graphical
> toolkits. Also, I have a first trial using AutoIt
> (http://www.hiddensoft.com/autoit3/; under Windows only, unfortunatelly) to
> automate tests of R functions involving GUI stuff (together with RUnit?).
> 
> 2) help in developing simple platform-independent GUI interfaces for most
> important features in this GUI API using the plain tcltk package provided
> with R (+ possibly the tcltk2 package in the SciViews bundle once it will be
> made platform-independent). Among others, this would consist in: (1) an
> object explorer, (2) a "views" display window (in the sense of those defined
> in svViews) and (3) menus/graph galeries/electronic reference cards, etc...
> as currently implemented in the docking windows of SciViews R Console.
> 
> 3) any initiative to continue the integration of Python + wxWidgets with R
> (it still remains my preferred way!), that is: either to continue James
> Wettenhall's project using RSPython + R-wxPython package, or a different
> solution, possibly using Rpy. I would definitely support dialog boxes with
> such a solution in my svDialogs package.
> 
> 4) I am interested by integration of various projects together. It is no
> longer a secret that I support R Commander and work on solutions to
> integrate it with SciViews-R. The SciViews R GUI API could possibly benefit
> to R Commander by means of its graphical toolkit-independent dialog boxes in
> the future. Also, I think Rpad could be a better choice for the report
> editor than the current SciViews R Report application (of course, Rpad is
> more than that...).
> 
> 5) I like the idea of an addition of GUI features to Emacs-ESS because this
> user interface is platform-independent, mature and powerful. I would be
> happy if the R GUI API could help somehow here.
> 
> As you can see, there is a lot to do, in addition to the writing and
> documentation of the R GUI API itself. It will ony make its way if I get
> help... So, it is up to you, "R-SIG-GUI-GUYS" to decide if it is worth
> developing and implementing solutions with the R GUI API or not!
> 
> Best,
> 
> Philippe Grosjean
> 
> ..............................................<°}))><........
> ) ) ) ) )
> ( ( ( ( (    Prof. Philippe Grosjean
> ) ) ) ) )
> ( ( ( ( (    Numerical Ecology of Aquatic Systems
> ) ) ) ) )   Mons-Hainaut University, Pentagone
> ( ( ( ( (    Academie Universitaire Wallonie-Bruxelles
> ) ) ) ) )   6, av du Champ de Mars, 7000 Mons, Belgium
> ( ( ( ( (
> ) ) ) ) )   phone: + 32.65.37.34.97, fax: + 32.65.37.33.12
> ( ( ( ( (    email: Philippe.Grosjean at umh.ac.be
> ) ) ) ) )
> ( ( ( ( (    web:   http://www.umh.ac.be/~econum
> ) ) ) ) )
> ..............................................................
> 
> 


-- 

best,
-tony

---
A.J. Rossini
blindglobe at gmail.com