[R-gui] [RGUI] Where do you start?

[Duncan Lang]

Philippe Grosjean wrote:
> Erin Hodgess wrote:
> 
> >How would I start to build a GUI, please?
> >Should I learn Visual Basic, please?
> 
> John Fox answered:
> 
> >When I programmed the Rcmdr GUI, I took a look at several options including
> >Visual Basic, and concluded that, at present, Tcl/Tk via the tcltk package
> >was the way to go. The tcltk package is one of the recommended packages,
> >the resulting GUI works under all platforms, and the Windows distribution
> >of R installs with a basic Tcl/Tk system. The GUI itself can be distributed
> >as a standard R package.
> 
> >Beyond that, it's hard to give advice since you don't specify what the GUI
> >will do, who will use it, on what platform(s) it will run, etc.
> 
> John is right, Tcl/Tk is largely advised for building GUIs for R. It has the
> double advantage to run on all platforms and to be fully integrated into R:
> it is now installed by default by the setup of R for Windows (I presume you
> are interested by a GUI for Windows, since you speak about Visual Basic that
> runs only under Windows).

Well, "advised" might be a little strong.  The tcltk package was put
into the R distribution as a matter of convenience rather than a
formal decision to advocate or support the use of Tcl/Tk as the main
toolkit.  This bundling has given it a status that was never
discussed.  Iit does run on all of the primary platforms which is very
helpful.  However, it is an old toolkit that is not used for any large
application.  This is in contrast with Gtk, Qt, Swing, which have
richer widgets, more activity in development and are the bases for
numerous applications. Why the latter is important is that we have
been succesful in embedding R into other applications and using and
extending their GUIs.  This is possible with tcltk, but there are not
real applications that are in widespread use that we would want to do
this.  So tcltk is fine if it is a stand-alone GIO application that we
want to run within R. Otherwise, it may well not be the best toolkit to
work with.


> 
> At the time I started the SciViews project, it was not the case yet (four
> years ago), and I choose Visual Basic for various reasons. The R(D)Com
> server, a similar package from Duncan Temple Lang

Just for the record, the are similarities between R(D)Com and the
RDCOM* packages. However, the RDCOM* packages are a lot more general,
being able to create R objects as real RDCOM servers. So while they
both provide DCOM access to and from R, the model and possibilities
are very different.  In general, sending R commands to R
from other applications is bad programming. And not being able
to deal with general data types makes the R(D)Com package
most useful for simple tasks, but not a good bet for 
building maintainable, general software.

> and R plugs (from
> SciViews) do connect VB to R, if you really want to use VB, or VBA (i.e.,
> the "macro" language of Excel) it is possible.
> 
> You do not give much details on which kind of GUI you want to build.
> However, whatever your project, you should start form existing code for two
> reasons:
> 1) You will learn faster from an existing example,
> 2) If possible, you could try to make your code compatible with the existing
> project, in order to contribute to it instead of starting yet another
> different R GUI project.
> 
> The last year, there where a couple of different, incompatible GUI projects
> for R. Most of them are not evolving quickly, or are even idle (Rkwark,
> ObveRsive, Brodgar,...)? The one that leads to a fully-working
> implementation is R commander form John Fox, and it is 100% Tcl/Tk. A wise
> choice in this context is thus to learn Tcl/Tk, and to build GUI extentions
> that are "R commander-compatible", i.e., that use the same menuing system
> and the same main window with a logging feature. Just start from the Rcmdr
> package, learn its code (it is well written) and adapt it to your particular
> needs.
> 
> ***If everyone agrees to use R commander as a reference for buiding R GUI
> for their particular application, then we will all move together in the same
> direction***

And that is very possibly not the "right" direction.  What John (Fox)
has done is terrfic.  It had a particular focus and goal.  You still
seem to thing there is a single direction that is good.  I believe
that all of us that have given this a moments thought understand that
the complexities lie in the fact that there are many different classes
of users, and usage, and so we need very different interfaces, even
with the GUI-world, let alone the command line world.  A single user
will need to switch between different styles of interfaces for
different tasks.  That is why we don't need "a" or "the" GUI, but
instead GUI components that people pull up for certain tasks and that
are well written so that they can be extended in the object-oriented
sense and embedded within other applications.  We have ways of doing
this that work.

And the collection of widgets in Tcl/Tk is not necessarily rich enough
to do what some of us want to do.  And the programming model for Tcl
(not Tk) is, to say the least, "strained".




> 
> ... and we will be able to put all the various pieces of the puzzle together
> one day... This will contrast with the situation until today, with all those
> different projects moving in different and incompatible directions: what a
> waste of time and effort!

Or understanding of the real problem!

> 
> I recently adapted SciViews to make it compatible with R Commander. The
> lastest version (0.3.3, see http://www.sciviews.org/software/SciViews.htm)
> provides some additional nice features you do not find in the current R + R
> commander binome: syntax highlighting, code tips, electronic reference
> cards, assistants, automatic installation of Rcmdr library, etc... and very
> soon an object explorer and views (a graphical way to explore R objects).
> So, Tcl/Tk dialog boxes "a la R commander" also run under SciViews (Windows
> platform only), if you prefer it to the simpler default Rgui user interface.
> 
> Best,
> 
> Philippe Grosjean
> 
> .......................................................<°}))><....
>  ) ) ) ) )
> ( ( ( ( (   Prof. Philippe Grosjean
> \  ___   )
>  \/ECO\ (   Numerical Ecology of Aquatic Systems
>  /\___/  )  Mons-Hainaut University, Pentagone
> / ___  /(   8, Av. du Champ de Mars, 7000 Mons, Belgium
>  /NUM\/  )
>  \___/\ (   phone: + 32.65.37.34.97, fax: + 32.65.37.33.12
>        \ )  email: Philippe.Grosjean at umh.ac.be
>  ) ) ) ) )  SciViews project coordinator (http://www.sciviews.org)
> ( ( ( ( (
> ...................................................................
> 
> _______________________________________________
> R-SIG-GUI mailing list
> R-SIG-GUI at stat.math.ethz.ch
> https://www.stat.math.ethz.ch/mailman/listinfo/r-sig-gui

-- 
Duncan Temple Lang                        duncan at wald.ucdavis.edu
371 Kerr Hall
University of California at Davis