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 _______________________________________________ R-SIG-GUI mailing list R-SIG-GUI@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-gui
