[R-gui] Another R-GUI

[thomas]

> The major reason why r-sig-gui is idle for the moment is that there are
> currently no really collaborative projects undergone. Personally, I spend
> all my spare time to progress in SciViews. As I understand it, several
> other people (including you ;-) are also focused on progressing in their
> own code. This is nice, because it means we will probably have several
> solid ideas for DSC 2003. I hope we will cook something there that will
> ravive the discussion on r-sig-gui.

Well, there might be one thing we should be discussing before March 2003. I 
don't know, how all of you are approaching this, but I had a short 
conversation with the obveRsive-people, and we seem to have had some rather 
similar ideas on this topic:
Probably all GUIs will at some places want to show some dialogs, read a few 
settings (which variables/options to use etc) in those dialogs and then 
generate R-code from that. The projects might differ in how those dialogs 
should look, whether R-code is passed to R transparently or in the background 
etc. but in many ways, the functionality to be provided will likely be 
similar or even the same.
For my project, I therefore decided to implement access to tests and the like 
(should probably be extended to mostly any operation) as a sort of "plugins". 
That is, the dialog for calculating a t-test (the only thing I implemented so 
far, as a demonstrational example: http://rkward.sf.net/pics.php ) is 
actually constructed at run-time from an XML-file.
Similarily, the obveRsive-project is planning to use an XML-extension called 
Jelly, in order to implement such functionality as "actions".
Most likely other projects are using similar approaches, or might at least be 
interested. If we could agree on a common syntax/semantics for defining 
actions/plugins/whatever-we-chose-to-call-them, I think this would be of 
great benefit to all projects. It would mean, that we can easily share at 
least some parts of our work, even across projects that might be rather 
dissimilar on the surface.
Now in order to not have to do everything over again later, I think, we should 
try to agree on such a plugin-language as early as possible. Therefore, I'm 
attaching a copy of the sample XML-file, the t-test on my screenshot-page is 
created from. It certainly does have it's weaknesses and can be criticized in 
many ways, but will hopefully serve as a starting-point for a discussion of 
what the requirements for such a "plugin-language" would be and later on, 
what exactly it should look like.

Thomas

Example XML-file is below. I hope your mail-client does not try to interpret 
it as HTML - in which case you will not see much. If it does, you'll have to 
view the raw message.


<!DOCTYPE rkplugin>

<!-- This is a simple example, of how a "plugin" might be configured. -->

<document>

<!-- The location-section determines, where the function will be placed in the
menu-structure and how it will be labeled. The "tag"-attributes are used
to identify the same menu across different plugins. The "label"-attributes 
will have to be translated somehow. -->

	<location tag="analyse" label="&amp;Analyse">
		<location tag="means" label="Means">
			<location tag="t_tests" label="T-Tests">
				<entry label="Independed Samples T-Test"/>
			</location>
		</location>
	</location>

<!-- The layout-section takes care of the layout of the GUI for this plugin. 
-->

	<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>

<!-- The code-section specifies, how the selected options will be translated
into code. Code generation is based on a simple search an replace-mechanism. 
-->

	<code>
		t.test ($x$, $y$, "$hypothesis$")
	</code>
</document>