[GUI] State, Attributes and Some basic widgets

[Glynn Clements]

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 <glynn.clements@virgin.net>