[R-gui] [Rd] R GUI considerations

[Thomas Friedrichsmeier]

Ok, I said I didn't want to embark in this discussion, but now I can't 
resist... 

> 1) New versions of R are released twice a year, with a yearly major
> update susceptible to bring uncompatibles changes somewhere. Since those
> changes are done by people probably not using your GUI, they
> unvoluntaring introduce uncompatibilities with your GUI. I experience
> this with SciViews-R, and I must say it happens too often to be
> overlooked. Now, if a big part of your code is in a R package, using
> good test units, (a) you are warn immediatelly of uncompatibilities, and
> (b) everybody can make the changes if you don't have time to do it right
> now. If it is in a foreign language, you have to use your own test
> units, and there is less chance that some R user can make the correction
> himself, because not all R users know your foreign language. The result
> is: a (sometimes) long delay between R versions and compatibles GUIs
> versions.

a) Unit tests are doable easily (though I admit, I don't have them so far).
b) In relying as little on R for GUI-stuff, as possible, I already rule out 
one entire class of incompatibilities.
c) Only the _GUI_ is done outside of R. The GUI (at least most parts of it) 
basically just creates R code (using a templating language to retrieve GUI 
settings). This R code is then evaluated just like it would normally be on 
the command line. No black magic involved.
d) No C internals involved either. As mentioned in c), the GUI creates plain R 
code as strings. The actual interface to R is - well, relatively - simple. 
And plugin writers do not even need to know anything about it.

> 2) The second reason is precisely the initial subject of the thread: we
> need to collaborate. How would you share code written in Java, versus
> C++ versus Python versus Delphi, ....?

a) I'm perfectly willing to share my plugin-framework (which will see major 
improvements in flexibility and reusability in the next few months), and to 
collaborate on making it better, adapted to other GUIs needs. The plugin 
approach itself is designed to be platform/language independent. Of course 
I'm aware, nobody else on this list is really interested in this, currently.
b) I do not think GUI code is the one and only point where R GUI projects can 
collaborate in a meaningful way. In previous mails, I've pointed out two 
major other areas. My "don't do it in R" philosophy only concerns the GUI 
stuff (I've been more radical, before). Also, I'd like to once again advocate 
that collaboration-efforts should be organized into strictly separate 
"modules", as much as possible. Some projects will use a common approach on 
all the modules, some will only collaborate on one or two areas, but follow 
different approaches on other aspects.

Keep it small, keep it simple. If there's any hope to ever get past 
discussions on which GUI toolkit is best, etc., I think this is probably a 
rule to follow.

Regards
Thomas Friedrichsmeier