[R-gui] (renamed) What do we do?

[Thomas Friedrichsmeier]

> Mak Myatt wrote:
> >Please humour me on this but I have become confused about the subject of
> >our deliberations.
>
> and in another message:
> >What is stopping ME from getting my hands dirty is that, without
> >agreement that this is the way to go, it might be a lone enterprise which
> >will amount to so much wasted effort.
>
> These are really pertinent remarks. I observe, a little bit disappointed,
> that we all spend much time in endless discussions on what to do, and what
> not to do... but nobody really moves forward in taking concrete
> initiatives.

I have come to think, that the "endless discussions" are still partially due 
to one or more misunderstandings. I support Phillippe in that we really 
should start making concrete steps, and as part of that I view the draft I 
suggested for a common plugin-specification. Let me try to sum up very 
shortly the premises that made me arrive at thinking, that such a 
specification would indeed be a good idea. Maybe then we can spot, where 
exactly we don't agree (if there is still disagreement, which I suspect):

A1) We have ultimately failed in agreeing on one single large project. Rather 
we have split up into several different ones. Some of those projects may 
fusion at some point of time, others may be given up. Still, we will have 
several different R-frontends.
A2) We have also failed at trying to agree on a common toolkit/general 
approach. As a matter of fact, this is one of the reasons for A1. Also, we 
all have an opinion on which toolkit/approach is best suited for our needs, 
but unfortunately we don't agree on which one that is. Discussions of the 
form lets simply all use Tcl/Delphi/whatever are completely futile (as are 
discussions "extend R to have a GUI" vs. "GUI around R").
A3) Apart from toolkit and general approach, there are a number of further 
important differences between projects.

B1) Despite A1-3, many, if not all projects will want to offer a GUI-dialog 
for e.g. a t-test.
B2) Despite A1-2, there are only so many different ways to do a GUI for a 
t-test "in principle".
B3) This "in principle" (i.e. the thing that all GUIs for a t-test will have 
in common) can be formalized in a relatively straightforward way.
B4) B3 is possible without sticking closely to any particular toolkit.
B5) since B4, it can be done in a way that is useful to projects using 
different toolkits/approaches/differing in other ways.

C1) There is a _lot_ of problems to which not only B1, but also B2-5 apply, 
even though B1-5 may not apply to _all_ problems.
C2) from C1 and B5 it seems reasonable to try to come up with such a 
specification, and we will be able to share a lot of effort despite A1-3.

I hope this is explicit enough, so we will be able to spot, where exactly it 
is that we disagree.
Thomas