From thomas.friedrichsmeier at ruhr-uni-bochum.de  Mon Oct 17 12:57:10 2005
From: thomas.friedrichsmeier at ruhr-uni-bochum.de (Thomas Friedrichsmeier)
Date: Mon, 17 Oct 2005 12:57:10 +0200
Subject: [Rd] [R-gui]      R GUI considerations
In-Reply-To: <43537220.1070705@sciviews.org>
References: <4350FB09.3020503@sciviews.org>
	<1129490486.5518.140.camel@localhost.localdomain>
	<43537220.1070705@sciviews.org>
Message-ID: <200510171257.10940.thomas.friedrichsmeier@ruhr-uni-bochum.de>

Hi Philippe,

> I answer to Marc's email, because I think it is the most constructive
> one. I am a little bit dissapointed that the discussion about R GUIs,
> whatever the initial subject, inevitably shifts to an endless discussion
> about which graphical toolkit to use, and whether one should interface
> it directly, or by means of an intermediary language perhaps more
> suitable for handling widgets events.
>
> Should I recall that this thread is *not* about which graphical toolkit
> to use, but is trying to trigger a discussion on how could we work
> together to avoid duplication in coding for R GUIs, and perhaps, join in
> a common project. Something totally different!

ok, I misunderstood you then. I thought you were in fact talking about drawing 
up a common ultimate R GUI project. Then in fact, discussions about which 
toolkit to use, etc., would arise quite naturally. And that is, what I wrote 
in my last mail, what I don't think will ever lead anywhere.
If you're talking about finding certain defined areas of collaboration, I'm 
all for doing that. I don't think I will attend UseR, but I'm certainly open 
to discussions of this sort. I support the idea of a wiki.
Here are some thoughts, on what I think might be areas of collaboration:

1) You talk about an API for R GUIs written in R. To me personally, this is 
not an attractive topic, as my approach is to do _all_ GUI stuff outside of R 
(I think of R more as an evaluation backend in rkward). Of course this is no 
reason against starting such a discussion. However, in addition, I'd like to 
bring in my idea of xml-specified GUIs again (this is useful in my approach, 
but probably not so much in yours). This could be discussed as a _separate_ 
topic.
2) As I mentioned in the last mail: Drawing up a flexible output format, that 
will allow small modifications on the fly. This includes R functions to 
generate such an output format. Something like R2HTML, only more flexible, 
allowing for dynamic changes.
3) R library API enhancements. GUIs have some specific needs for the R 
(C/library) API. Such needs do not seem top priority for the R core 
developers (no offence intended). Last week I proposed some API additions to 
the R C API on r-devel, but never received a reply. I have several more items 
in mind that I would like to see added/changed in the main R library. 
Probably it would be good to have some collaboration on identifying, and 
elaborating our C-API needs.

Many more areas of collaboration could probably be identified. However, I'd 
strongly advise to keep such topics small, well defined, and separate from 
each other. Otherwise we'll once again end up in the discussion about the 
great merger of all R GUI projects, which I don't think will lead anywhere.

Regards
Thomas



[Rd] [R-gui] R GUI considerations
Thomas Friedrichsmeier