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

[Thomas Friedrichsmeier]

Am I the only one thinking about it this way? If so you can tell me to simply 
forget it, but until then I'll try yet another way to argue for my point.

First of all I should state again: This plugin thing I'm proposing is NOT 
about describing an entire R-frontend. It's about trying to share our efforts 
on stuff that will be in principle the same across all applications. All 
projects are still free to hard-code or otherwise implement anything they 
like that can not be realized using this plugin-language.
If this plugin-language is to be useful to all of our projects, it should not 
become too complicated.
If we hope that Joe R. Expert writing a new custom module for R will also 
provide a plugin-description using this language, it should not become too 
complicated.
It should focus on the stuff that's really commonly needed. It will likely be 
far more effective to implement individual solutions for functionality that 
is not.
SPSS may not be a particularily positive example, but since I (unfortunately) 
happen to know it best: IMHO 100% of the "Analysis"-menu in SPSS is already 
covered in the draft I posted (and that without limitations like not being 
able to resize dialogs...). With the <graph>-tag which will of course have to 
be enhanced, I think at least 90% of the "Graph"-Menu is covered, potentially 
even the whole thing.
Ok, R can do a bit more, and the draft may not cover everything you could 
possibly want to do with R. It's only supposed to cover most of it - and I 
think it already does. It may be extended in some ways and improved in many, 
but the application will still have to provide it's own solution for some 
problems.
Why again, do I argue both against using a complete GUI-description language 
as used in most toolkits, and against even trying to approach the problem in 
a similar way?

> Just a very simple question (could't get into this interesting
> discussion before -- sorry for that): Why not use HTML itself? It
> provides both formatting language and visual editors (to which extent
> they are usable is just another point ;-) and is a well-known language.

It's a well known language, and it can do a lot. Correct. Personally, I never 
had much fun using HTML though. The reference alone can fill a small book. 
Every browser implements a different subset of functionality (not a problem 
in itself), and we all know what happens when someone is only testing their 
pages with IE. Sometimes, they don't just look bad on a different browser, 
often enough they don't even work at all.
Some browsers are several megs of downloads just for rendering HTML - and I 
don't even want to know, how many lines of code they are.
Moreover I've often enough seen websites, where every single page looks and 
behaves different. That may sometimes be justified for aesthetic reasons, but 
this is not something we want in a productive GUI.

> In addition to this, I think, finding some widget rendering HTML itself
> should be possible for most (all?) platforms. This could minimize work
> while still providing the most functionality. Of course, this would also
> allow to use some platform-specific extensions (e.g. Active X controls
> on the Windows platform) available for the supported "browser widget".

And this is another good example of what we do NOT want. Your application may 
decide to use some fancy widget available nowhere else for some 
functionality. But what I'm trying to propose is something common that all of 
us can use. Make it easy to share common stuff, develop your own solutions 
for fancy stuff. That's what it's all about.
Again, of course there are complete solutions for creating almost arbitrary 
GUIs available. Be that HTML, be it the GUI-descriptions of 
Gtk/Qt/Delphi/whatever. Now consider we e.g. use the Qt way. That would mean 
for most applications to write a complete full featured interpreter for 
translating this into e.g. a Gtk-GUI. I think at this point, we're off better 
to simply use individual solutions, this simply is not of common value.
Instead we should try to come up with something that can realistically be 
implemented before the end of time and that still does most (but certainly 
not all) of what we want.
This means leaving certain stuff out. I don't think a plugin-writer should be 
able to make e.g. the dialog for an independent samples t-test look and 
behave totally different from that of a dependent samples t-test. We just 
don't need that (let alone want that), so we keep it out.
Also, wherever possible, we use simple fallback-mechanisms. If we want to read 
in some discrete value, we use:

<input type="number|string" 
typehint="lineedit|textfield|spinbox|slider|dial..."/ id="string" 
label="string">

Now suppose the plugin-writer thinks a dial would be the thing to use in this 
place, but application A has never even heard of a dial - it will simply use 
something else that can serve the same function. The dialog may not look just 
as pretty then, but it will still have the same functionality.
In contrast, look at the way Qt does this:

    <widget class="QDial">
        <property name="name">
            <cstring>Dial1</cstring>
        </property>
        <property name="geometry">
            <rect>
                <x>220</x>
                <y>100</y>
                <width>91</width>
                <height>71</height>
            </rect>
        </property>
    </widget>

Now what if the application does not know, what a dial is? I will obviously 
fail miserably.

If you can find the time, please have another look at this short XML (not 
quite sure, whether it's still in accordance with the draft, but you'll get 
the idea):

	<layout>
		<row>
			<column>
				<varselector id="vars"/>
			</column>
			<column>
				<varslot type="numeric" id="x" source="vars" required="true" 
label="compare"/>
				<varslot type="numeric" id="y" source="vars" required="true" 
label="against"/>
				<radio id="hypothesis" label="using test hypothesis">
					<option value="two.sided" label="Two-sided"/>
					<option value="greater" label="First is greater"/>
					<option value="less" label="Second is greater"/>
				</radio>
			</column>
		</row>
	</layout>

and at what RKWard made of it (of course your application may decide to make 
it look different): http://rkward.sourceforge.net/images/ttest_plugin.png 
It may be the pride of the author, but I really think, there is a certain 
beauty in creating a full dialog from an XML-section simple as this. It is 
possible by assuming that certain functions (like selecting an R-object) will 
be used quite often in an R-frontend and therefore should be represented by a 
single tag, and that certain functionality (like e.g. a "help"-button) should 
be present in almost any dialog, and therefore does not have to be defined 
explicitely (it might be made possible to mention explicitely, that there 
should be none, however).
Moreover, whoever wrote such a plugin would not even have to know, that RKWard 
offers a code-preview.
Of course, this means sacrificing flexibility to a certain degree. Again 
however, considering that we're not trying to describe an entire application, 
but only custom _plugins_, I think this is definitely the way to go.

Thanks for your time.
Thomas