Please note, that the questions I ask are really meant as questions, and are not purely rhetorical.
I think there should be finer granularity than that. We shouldn't use
Delphi's scheme of counting things in pixels (Delphi has problems when
you change fonts, or change screen resolutions), but some sort of
device independent coordinates (e.g. the dialog coordinates run from 0
to 1 in each direction) would be better than assuming it's a grid.
I think assuming it's in a grid is not all that bad as a start. After all, if the widgets do look different in different projects, it's dangerous to specify even relative sizes. I admit, that the idea of rows and columns is somewhat inspired by Qt, which uses rows and columns for layouting, but I guess something like this is available in other toolkits, too?
Anyway, we might of course add some percentual width-attributes (kind of like it's done in HMTL-tables), which could be taken as a hint to the layouting-engine, thereby adding a little more flexibility.
- some sort of widget that lists available objects (the "varselector" in my
example)
I think we should start at a lower level (a widget that gives a list
of strings to select from), and then implement a list of available
objects as a string list widget that has been populated by the names
of available objects.
Well, this may be going a bit into details already, but do we really need this? Do you ever need to select strings from a list, that do not represent R-objects? Of course, if we really need this, that should not be much of a problem, and RKWard's implementation of a "varselector" acutally works much like that internally.
- a widget that can hold a (single) object (the "varslot"), and will
probably
make some specifications about what types of objects it can hold (like the
attribute type="numeric" in the example)
- maybe a separate widget that can hold one or more objects, but basically
acts the same (might instead simply use a more generalized "varslot")
- maybe a separate widget that can hold a single constant value (number or
string)
- a widget that can be used to select interactions between variables
selected
in a "varslot"
In the same way, we want the lower level components that make these up
to be available.
Do we?
- radio-buttons
- checkboxes
These are low level.
Ok, admitted.
- a widget representing a text/label not directly attached to any of the
other
widgets
No need to make this special now, it's just a low level label...
True, but I was actually trying to give a _complete_ list, i.e. this is all the widgets, I think we need (at least for a first draft).
- a widget represent a line or other separation used for layouting purposes
We often want boxes, so it might make sense for that to be the lowest
level, with one style being a box with only one side visible.
Sounds reasonable.
We also need buttons, and the ability to attach actions to user
actions. (E.g. click on a button or change the entry in a widget and
execute some R code).
Do we? Of course the GUI-itself does need some buttons e.g. for executing R-code, but there should be no need to explicitely define those. They should simply be generated by the application, not stated in the "plugin".
I'm not sure how many of these we want, but
there could be a lot. For example, Delphi allows 16 different kinds
of events to be triggered by a button: clicks, mouse
move/push/release, context sensitive help popup, 3 for drag and drop
functions, 2 for "docking" functions, 2 for focus entering/leaving the
button, and 3 for key presses while the button is focussed. Since we
don't want all of these from the beginning, but we might want some of
them later, I think we should make it easy to add additional events to
components.
I still believe, we're partially talking about different things. Whether the application wants to show a help-menu on a right-click somewhere or on a hover, whether something gets pasted into a field or typed manually etc. should entirely be the responsibility of the application, not be defined inside an XML-file to be shared across projects. That's what I mean when talking about "high" level - the XML-specification should really say nothing about what happens when you right-click on some button. It should allow you to state: "Ok, I need this standard-R-widget here that represents a numeric value. If it happens to provide the functionality for a context-help (by whichever means), display the text specified. If it happens to support a header-label, display that other text here. I don't care what it looks like, and I don't care, whether the value is read from a silly slider or some more serious control. Just put it there."
We should also have a tree view widget, and a free text entry widget.
It probably makes sense to have a widget for entering longer texts, but do we really need a separate tree-view? What else would you want to put in there, if not the available variables?
I'm not sure why this needs to generate R code. Why not just have a
function to retrieve the values of all widgets that have values?
Umm, yes, exactly that. And that function would result in some R-code. Or are we talking about something different here?
Let me post again the section in my example:
<code>
t.test ($x$, $y$, "$hypothesis$")
</code>
Here my "code-generation" is to simply replace everything inside $$ with the values in the GUI (I have two "varslots" with tagged "x" and "y", and a group of radio-buttons tagged "hypothesis").
I'm simply not sure, whether a simple search-and-replace like this is flexible enough.
PS: No need to CC me, I'm on the list (with a different mail-account)