[R-gui] Re: R-SIG-GUI digest, Vol 1 #18 - 5 msgs

[thomas.friedrichsmeier@ruhr-uni-bochum.de]

Hi!

> A good point. I was thinking more of a split development effort in
> which there was some form of GUI shell around R with (e.g.) menus
> customisable though a simple text file that describes menu names and
> hierarchies and specifies calls to R functions as well as turning on
> and off various aspects of the GUI. Such a GUI could have things
> like window management, an embedded code editor component, a tabular
> data-editor / viewer, and an 'object inspector'. This would be the
> "GUI around R". Front ends to functions (called from menus or from
> the command line) could be written in R controlling a Tk drawn
> dialog. I think this approach has the advantage of using those with
> skills and interest in writing and porting binary code to write the
> "GUI around R". The task of those with less interest or less skill
> in this area would be to write the R/Tk wrappers to R functions.
> This approach plays to the skills of some people in this group as
> well as to people inside and outside of this group who can write R
> code. I see this more as a manpower issue than a technical issue ...
> I am sure there are better technical solutions to what I am
> suggesting here but these rely, I think, on the participation of
> only a small number of highly technically competent people.
> 
> In addition, we already have the Tk interface (mostly) up and
> running. It seems a bit of a shame to put this maturing development
> aside and start anew.

I think we're not contradicting each other here, or at least not
fundamentally. Definitely approaches of "extend R to have a GUI" will
probably want to use the Tk interface. That's perfectly fine, and 
this
discussion really is not meant to be against using the Tk interface.
Rather acknowleding that not all projects will chose this approach,
the idea is to put up a standard that can be used in both contexts. 
So
for instance a Qt-application of the "GUI around R"-type would parse 
a
plugin-specification into Qt-widgets, while an "extend R to have a
GUI" approach could use the _same_ plugin-specification to build up a
Tk-dialog. I admit, I don't have much knowledge on how difficult this
will be to realize in the "extend R to have a GUI" approach. It will
definitely mean to write a parser/translator, which at first is 
simply
additional work. Work on the Tk interface is however complementary to
this, not a contradiction. The idea actually also stems from the
"manpower issue". It will mean to write a translator for each 
project,
but after that, a great number of plugin-specifications could be
shared across projects without modification. Also the idea is to make
writing a plugin as easy as possible, at least for common patterns of
problems. That's why I propose to use a level of description like "in
order to calculate this test, you need to chose two vectors..."
instead of "if you right-click this button, then..." as the primary
(but not necessarily only) level of specification.

> I don't think anyone would claim that the tcltk R package (or R or
> Tk or TCL for that matter) are just perfect. The package could,
> however, form the basis of at least part of the development effort.

Yes, it will be very valueable to some projects, but unfortunately 
not
to some others. This does not mean to dump it altogether, but simply
to add a step in between that is abstract enough to be of use to all
projects.

> As an aside, I must say that a "GUI frontend with lot of context
> menus and toolbars" sounds more complicated than "complex". Can't we
> have "just enough" widgets rather than "lot[s]". I worry when I see
> words like "complex" used in the context of user interfaces.
> "Simple" is more in my line.

My approach is also about having "just enough" widgets, although with
a bit of room for elaboration by the particular frontend. So the 
basic
idea is, that a project could actually make use of only a very 
limited
number of different widgets like a lineedit, checkboxes and a
treeview, and construct everything from that. A more ambitious 
project
would be more elaborate - again building on the same plugin-
specification. The same holds for context menus and toolbars. Some
frontends may chose to offer a lot of those, some frontends may 
decide
to keep it simple. The only thing here that would go into the plugin-
specification is a short context-help text, which a particular
frontend may chose to make use of or not. All the stuff like "if you
right-click on a varslot, you'll be presented a dialog to chose
transformations from, you can apply to the object; if you shift-right-

click you will be given the option to rename the object on the fly; 
if
you do something else, something else will happen..." simply does not
go into the plugin-specification. A frontend will still be able to
offer this sort of functionality (if it likes to), simply because the
specification states, what the _function_ of a particular GUI- 
element
is, not in a prescriptive way, what it should look like. This is the
difference between simply requesting a "lineedit", which might be 
used
for all sorts of different functions, and a "varslot", which some
frontends will also render as a lineedit, but of which they will 
know,
what it is used for. "Complex" then, may be a bit of a misnomer. The
plugin-specification should stay as simple as possible, and a 
frontend
is free to keep it just as simple. At the same time, another frontend
is just as free to provide all sorts of fancy pop-ups based on the
_same_ plugin- specification.

Thomas