[R-gui] Re: XML specifs for R GUIs dialog boxes

[thomas]

> And also, Glad, Gtk's interactive GUI developer also has an XML format
> that it uses.

Yes, and Qt uses one, and Delphi uses something functionally equivalent 
(though not XML) and I wouldn't be surprised to hear about a lot of other 
toolkits using something like this. Simply because it's a good idea.

> It is definitely useful, nay essential, to avoid
> inventing a different version of something that exists. Deploying
> standards from other domains is vital for us in statistics.

I would however argue, that what we want does not exist, or at least not 
completely. While it is definitely a good idea, to use e.g. more HTML-like 
syntax whereever possible (and my draft should really be enhanced in this 
respect), I don't think any one existent standard provides what we need, 
which is
a) Something we all can live with, i.e. definitely nothing closely related to 
a specific toolkit.
b) Something that makes it as easy as possible to provide standard core 
functionality commonly needed in R-frontends (that is we do at least need 
something like what I called a "varslot", which takes an object, knows, when 
that object is valid, provides an interface to attributes of that object 
(like the .type -function I proposed)...). I.e. we need some "high-level" 
widgets (which might of course be added to any existent standard). Also 
having those "meaningful" widgets that are used for a certain function (i.e. 
are not simply some lineedit), has the advantage, that the application can 
provide additional functionality that just makes sense (e.g. an easy way to 
apply transformations like log () to an object, but NOT try to offer that 
functionality for something that will be used e.g. as a label (which might 
show up as a lineedit as well)).
c) IMHO, for the above reason, and also in order to make it easy for an 
application to provide a consistent look-and-feel across plugins (potentially 
created by very different people with very different tastes), the 
specification should actively discourage composing common functionality out 
of low-level widgets. I.e. although it will probably be possible in the final 
specification to construct something that will act as a "varslot" from simple 
"atomic" widgets, this should NOT be the way to go, but rather let the 
application make the decision what a "varslot" should look. It might look 
different in another application, it might offer different nifty features in 
another application. But ALL widgets used for selecting an R-object should 
look the same in a given application.

These again are the considerations that make me argue, we should try to start 
out with "complex", "high-level", "specialized", whatever-you-may-call-them 
widgets, and only then add in flexibility as required, not the other way 
around. And not the way that layout/flexibility-centered GUI-descriptions 
like used in common toolkits do it. We need something you can build an 
R-frontend with. If you can also build a doom-clone with it, without loosing 
simplicity and easy of use - fine, but that's not our primary goal.

To be a bit polemic (please don't take this as personal, I just think it 
illustrates my point): I can see, that it's not always a good idea to 
reinvent the weel, but I think the w3c was right in it's decision not to base 
HTML on the TIFF-format extended by the ability to define areas acting as 
hyperlinks, even though any static content can very accurately be described 
in the TIFF-format.
Whatever standards we may agree on, at least most of our projects will have to 
write a custom implementation for interpreting that standard anyway. So it's 
not like, just because e.g. Qt provides a cool dialog-editor and generates a 
pretty XML-description from that, we can simply use that and are done. This 
would be pretty fine for Qt projects, but not for the rest of the world. So 
when trying to agree on a standard, let's find one, that is tailored to our 
needs right from the start. We may disagree in some ways on what exactly 
those needs are, but I think we can agree on the fact, that the way e.g. 
Qt/Delphi/name-your-toolkit-here defines a dialog in XML is not the way to 
make all of us happy. Based on that insight, let's try to design something 
useful.

Thomas