[R-gui] Re: R-SIG-GUI digest, Vol 1 #8 - 4 msgs

[Mark Myatt]

Philippe Grosjean wrote:

>Peter Dalgaard <p.dalgaard@biostat.ku.dk> writes:
>>...
>>Mine too, obviously, although maybe for other reasons: I think it is
>>important to have the GUI scriptable in R, and the Tcl/Tk model is the
>>best tested one out there, and cross-platform except for some
>>low-level issues.
>
>>I do occasionally have doubts, though. Sometimes the Gtk approach and
>>all its promises about integration with other tools looks attractive,
>>but I still think we need the internal scriptability. Some efforts in
>>that direction are gnocl (Tcl interface in the style of Tk) and stklos
>>(object-oriented Scheme interface). However, both of these are in
>>their infancy, and essentially one-man jobs.
>>...
>
>Interesting enough, the opposite option (R driven by the GUI) is not
>completely stupid.

Not stupid at all. I think that the availability of the Tk bindings in R
means that the front-end to functions can be scripted in R. The
advantage of this is that development can be incremental and move
forward on several fronts.

We could start with a simple 'GUI' with (e.g.) an editor, output, and
inspector window that allows R code to be submitted to R and output
returned. The menu system of the GUI could be scriptable ... a menu item
can be added and associated with a call to an R function and that
function would be a Tk front-end to (e.g.) glm(). The GUI handles
submitting of commands and capturing and displaying output but
everything else is done by R.

This would mean that one team can concentrate on the GUI (using whatever
tools seem best for that). Another team can concentrate on common user-
interaction elements in R/Tk (e.g. formula specification, object
selection) that would be common to many front-ends. With this in place
front-ends to functions could be written gradually by anyone familiar
with R and the Tk bindings or added by the authors of libraries. Neither
team would be waiting on the other team to complete since Tk front-ends
can be called from the terminal window (or from a stop-gap R/Tk front-
end). Without R/Tk front-ends the GUI still works as an IDE.

There is merit in discussing tools but I think we also need to adopt a
development strategy that can open development up to as many people as
possible. I think this would mean using the R language as much as
possible since we all have some knowledge of it. I think a development
entirely in (e.g.) C++ with Qt (or whatever) could not attract a large
body of developers.

Mark

--
Mark Myatt