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

[Thomas Friedrichsmeier]

I think we're still having a misunderstanding here. The plugin-thing I'm proposing is again NOT about finding a way to describe an entire R-frontend. I seriously do hope that at least some of our projects will come up with truely innovative new stuff that can not easily be modeled as a plugin. Still  (I think) there will be lots of more or less "standard" functionality that implies a lot of work, but leaves only so much room for innovations. IMHO, one example of that is a t-test, and looking e.g. at the Analysis-menu in SPSS, I find it full of similar stuff. All projects will have to implement at least considerable parts of that, and I'd hate to see all of us doing it over and over again for each project.
Also, I'm not even talking about all of us doing this in exactly the same way. That's why my specification is what Phillipe calls "voluntarily incomplete" - the idea is to leave a lot of freedom to an interpreting application, and still use a common base.
Further, when you talk about "here's the t-test widget", I feel we're still talking about fundamentally different things. I'm not talking about a t-test widget. I'm talking about a rather abstract description that specifies the core-functionality of (for example!) a t-test GUI, namely "for a t-test you need two numeric vectors and you can specifiy a number of options". I'm trying to talk as little as possible about how this should be presented, and I'm not talking AT ALL about which toolkit to use (use Tcl/Qt/Delphi/your-own-toolkit(tm)/whatever. I'm not AT ALL talking about how data/commands should be passed to/from the backend. I'm not proposing to implement a t-test widget, but a simple common language, that all our projects will understand. They will NOT understand it in exactly the same way. E.g. RKWard uses Qt-widgets, but others will use Tcl-widgets. They will interpret the "t-test plugin" to provide the same core-functionality in a certain dialog, that's all. And if you have a radically different idea on how to design a GUI for a t-test, that can not be modelled using our common language, you simply will not use this plugin (but may still use others). (Besides, if you can think of a radically different and incompatible-with-my-draft way of designing a t-test dialog, I'd be very interested to hear about that!)
I am in no way trying to take away freedom of design or implementation. I am not saying you should create your entire frontend using only the plugin-description language (I'm not even trying to do that myself). I'm trying to avoid duplicate work in some areas, not trying to force all frontends to be the same.
Further, when you say, we can worry about the details later, we must again be talking about entirely different things. I want to start an application NOW, and _part_ of it will be an interpreter, that can create dialogs from the plugin-specification language. I do not want to do that work completely over again at some point of time. This is why I want a half-ready specification as soon as possible. Of course we will still be able to change some things later, but IMHO it is not impossible to come up with something functional in a matter of weeks (if not days). If in my draft you find something which you think is fundamentally wrong or incomplete, please comment on that. But keep in mind that you will not have to create your whole application this way, but it is only meant to describe some "standard" functionality.

> Rather than discussing, it would be better to be coding and
> displaying examples.

Then please do take a look at RKWard-codebase (class RKPlugin should be your starting point for this), screenshots, and the example XML. This is a working example of what a plugin-specification could look like and what a "translator" can make of it. And once again note, this is NOT what any "translator" has to make of it - yours has a LOT of freedom to do it different. I am again not saying all our applications should do the same thing - but if you're looking for an _example_, it's there.

> Everyone wants to run a project and being in control; but to agree on
> goals with the final outcome requires people to swallow something and
> take up pieces, as well as "release ownership and trust others".  It's
> the problem with opensource, and why successful projects (like R) mean
> something about the people involved.

I'm not trying to make anybody swallow anything. I'm trying to offer a way by which duplication of a lot of effort could be prevented. If you don't like some of it, don't use those parts. If you don't want any of it, don't use it at all. Once again, this is not about writing an entire application or a framework for one, but a standard for PLUG-INs (and you could even have different standards for even better (but specific to your app) plugins besides this one). Simple standard functionality that does not affect the operations of the rest of the app. That's all. I don't see all that many "goals" we have to agree on here. And if you don't want to "trust others", you can simply review all available plugins before including them into a distribution of your app.

> And it's fine to figure out the primary use cases as well as to agree
> on definitions first, before coding.  I think this is why people are
> talking at loggerheads, though it's somewhat useful.  In fact, it
> would be worth writing out what you want to do.  Here's my interests:

> Audience: moderate/experienced programmers interested in data analysis
> Tools to develop: GUI/IDEs for largish projects using modern
>     programming methodologies (literate programming, extreme
>     programming, aspect-oriented programming).
> Languages: Statistical languages, such as S(R/S-Plus); SAS; Stata;
>     SciPython; XLispStat, and any that interface with them.
> Goal: support both programming and data analysis cross platform and
>     more importantly, UNIFORMLY
>     cross-language. (extraction/display/manipulation of
>     electronic documents, workbooks that support literate statistical
>     analysis)

> Sounds like SciViews, eh?

The only thing I'm trying to do here right now, is to propose a "one size fits all"-approach to the vast mass of uninteresting (from a creative point of view) dialogs for all sorts of uninteresting (from a frontend-designer's point of view) statistical tests. And "one size fits all" also means, that I'm neither interfering with any of your goals, nor am I introducing new ones. I don't care what you use as a backend, I don't care what programming language you use, I don't care what platforms you intend to be compatible with, I don't care how you pass data (or whether you "pass" it at all). If you don't believe me on this, please read my draft again (and point out where I'm introducing unnecessary limitations). If you think this to be "premature flexibility" - I say it's a realistic approach (and it's not even complicated or hard to implement - look at RKWard codebase, if you don't believe me).

Thomas