Wolfgang Thaller wrote:
It seems that the discussion about how to represent widget attributes has died down again recently. I'll try to get it going again...
I'll try to list a few very basic widgets and their most important attributes. I'm using Apple's terms, I don't always know the "proper" Windows, Motif or GTK terms.
Push Button Read/Write attributes: Label (String), Enabled (Bool)
The label is more style than state; it seldom needs to be set programmatically; text output (e.g. status indicators) should use a read-only text widget.
Callbacks: onClick
"onActivate"; "onClick" implies use of a mouse. If the callback is passed the event which triggered it (which is normally the case for Xt callbacks), it's worth reminding the programmer that it won't necessarily be a mouse event.
Check Boxes and Radio Buttons Read/Write attributes: Label (String), Enabled (Bool), Value (Bool) Callbacks: onClick
Static Text (a.k.a. Labels) Read/Write attributes: Label (String), Enabled (Bool; yes, at least on Mac OS, static text can be greyed out)
The comments for push buttons apply to both of the above.
Scroll Bar: Read/Write attributes: Value, minimum, maximum, size of visible part, step sizes etc... Callbacks: onScrollStart onScroll onScrollFinished (or something like that)
Motif has separate callbacks for each type of motion: decrementCallback incrementCallback pageDecrementCallback pageIncrementCallback toBottomCallback toTopCallback dragCallback valueChangedCallback If one of the first six callback lists are empty, valueChangedCallback is used in its place. Also, Motif has "scale" widgets (Windows has something similar), which should be used for generic value input; scroll bars are specifically for scrolling.
What attributes are there that cannot be changed after creation or that have no sensible default? (Yes, I do consider "" to be a sensible default for a button label)
For all Xt widgets: colormap depth screen For all Motif widgets: layoutDirection stringDirection Scrollbar: orientation Also, XmRowColumn has a lot of attributes which can only be set at creation time; it also has a lot of pseudo-attributes related to menus which can be set at creation time but can't subsequently be written or read.
On Widget Names: Then there is the Xt-style widget name, which would need to be specified on widget creation, and which would then be read-only. Is it really necessary to have this on all platforms? I gather it is used for looking up customization from X resources - does this make sense if the widgets have been created programmatically using a cross-platform interface?
Yes.
People targeting other platforms first wouldn't know what to use the name for, and why it's a good idea to specify a proper name. If the interface is loaded from an UIL file, then of course there would be a Xt widget name, but do we need it even in programs that don't care about UIL files and X resources?
If you want code to work on all toolkits, you have to provide it. It
would also be necessary if we wanted to implement some of Xt's
features (e.g. customisation through external files, e.g. for I18N)
for other toolkits.
BTW, on Windows, dialog controls normally have "names", except that
they're integers rather than strings.
This also simplifies coding. The UI creation code doesn't need to
store lots of handles for later reference; code can obtain the
run-time handle using the widget's pathname.
--
Glynn Clements