[Rd] [R-gui] R GUI considerations (was: R, Wine, and multi-threadedness)

[Thomas Friedrichsmeier]

Hi,

> Qt is C++, cross-platform using native widgets on OS X and Win and (since
> more recently) available without fee or license woes provided it is used
> for GPL'ed code.
>
> So it satisfies both the requirement to make it look and feel native
> whereever possible, and satisfies the preference for an OO paradigm for GUI
> programming.
>
> Would it be an alternative?  Is it worth a prototype app?

If you seriously consider writing a Qt app, please have a look at RKWard (at 
least to find out, which portions of the code to reuse). RKWard is not a pure 
Qt app, however, but a KDE app. KDE 4 is promised to be cross-platform (but 
won't be released for another year or so), so I hope RKWard will be 
cross-platform, then.
Also, note that RKWard uses a somewhat different approach, than most other 
R-GUIs (as far as I know), in that _all_ the GUI stuff is done in C++-code 
(or plugins). There is no API to build GUI(-elements) from R in rkward, and I 
don't have plans to add that in the near future.
On the discussion iniated by Philippe: I don't think there will ever be a 
single united R GUI. It's not like this discussion has not come up before. I 
agree this has something to do with individualistic developers, and I'll 
admit to being one myself. But there are other reasons as well.
What I do believe, is that there could be collaboration in some areas. Years 
ago I proposed a standard for defining some GUI-elements. Philippe was pretty 
much the only person expressing interest at that time, but now uses an 
entirely different approach.
Another area could be drawing up a flexible output-format, and R-methods to 
create such output. R2HTML does a pretty good job, for the time being, but 
ultimately, we'll want an output format that does some more abstraction, for 
instance, to allow changing the number of digits to display on the fly, etc. 
If we could agree on a common standard for this, it could save all projects a 
lot of effort. (But no, I haven't worked out any specific ideas for this, 
yet).
I think you'll have a hard time, convincing any of the projects to give up 
their individualistic approaches (including any agreement, even on which 
programming language to use). All I can see is some projects might share some 
common standards.

Regards
Thomas