[R-gui] [Rd] R GUI considerations

[Philippe Grosjean]

Thomas Friedrichsmeier wrote:
> While I totally agree with the general directions of you mail, I don't agree 
> with your points 4 and 5.
> 
> 
>>4) What is the language that is working an all platforms R runs, is
>>perfectly compatible with R, and is always available once R is
>>installed? Well, R itself (i.e., the S language), of course! So, to make
>>sure your GUI code is most usable by the R community, write as much GUI
>>code as you can in S language... and if you think you can write
>>everything in you XXX language, think again, and you will realize that a
>>large part of that code can actually be written directly in R as well.
>>
>>5) There are new and better graphical widgets and languages appearing
>>regularly in the computer world. The best ones for making a GUI today
>>may be obsolete rapidly in the future. On the contrary, we all hope a
>>longer life for R. Thus, write your GUI code in R as much as possible in
>>a way it is independent from a particular GUI toolkit and interfacing
>>language. I say, as much as possible, because this is a very diffcult
>>task, given the specificities of each toolkit and language.
> 
> 
> This is a perfectly valid approach. However, I don't think it's the only one 
> to "tolerate" on R-SIG-GUI. Personally - and no, I don't really want to go 
> into a lengthy discussion of the pros and cons at this point - I follow a 
> radically different philosphy in this respect: Since R is _not_ designed to 
> be a GUI language, do as little GUI code in R as possible. Write a GUI that 
> can use R, and make it as easy as possible for R-experts to add functionality 
> to your GUI, but don't try to write your GUI in R. For all other things 
> (creating nice output and such), R is the language of choice, of course.
> And no, I'm not claiming, mine is the only true way to happiness. However:

I know, Thomas, that you would react here: writting features of a R GUI 
in the "other" language is a perfectly valid way of doing it... in theory!

In practice, it works also on all points except two:

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.

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, ....?

So, I admit that both approaches are valid (more code in the foreign 
language, or more code in R). But, in practice, and in 
collaboration/reusability of code in mind, only the second alternative 
is satisfactory. That said, it is my own experience. You have your own, 
different one.

> 
>>I think if you disagree with these "rules", you'r wasting your time. You
>>are then better to log off from R-SIG-GUI, even uninstall R if you are
>>so angry,... and enjoy life instead of wasting time fighting against the
>>$%*£&#! behaviour of R in your GUI.
> 
> 
> I just wanted to point out that maybe some of your rules are overly strict (at 
> least for me).

OK, a little bit too strong! Just that I am a little upset the 
discussion turns again on arguments on the same subjects.
Best,

Philippe Grosjean