[R-gui] Another R-GUI

[Philippe Grosjean]

> I'm not sure why this needs to generate R code.  Why not just have a
> function to retrieve the values of all widgets that have values?

Umm, yes, exactly that. And that function would result in some R-code. Or
are we talking about something different here?
Let me post again the section in my example:

<code>
   t.test ($x$, $y$, "$hypothesis$")
</code>

Just to mention the very elegant way used by Splus: all features of the
dialog box are described in a data frame. The data frame is passed to
callback functions that can modify some of its features and return a
modified data frame. In turn, the GUI actualizes the dialog box according to
these modifications.

Just a mention also, of the tcltk package approach, where every single
interaction with the dialog box is translated somehow into a R command.

These are two extremes approaches. I must admit I favor the first one,
because:
1) for Sciviews, the GUI needs to remain as much independent of the
"calculation kernel" as possible (the same GUI allows to connect to
different "calculation kernels" like R, Splus, Matlab, Octave, Scilab,
Ox,...) and
2) there is a difficulty if the dialog box is managed directly by the
calculation kernel: since the dialog box is event-driven, the calculation
kernel must be ready to respond immediately at any time when the dialog box
is displayed (otherwise, when the user clicks somewhere, there could be a
sensitive delay before the program responds if it is processing something
else and this gives the impression that everything is locked). Consequently,
either it is not possible to trigger (long) calculations during the display
of dialog boxes, or the calculation kernel must be reworked to allow some
king of parallelism (not easy!).

Philippe