[GUI] State, Attributes and Some basic widgets

[Wolfgang Thaller]

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)
Callbacks: onClick

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)

Scroll Bar:
Read/Write attributes: Value, minimum, maximum, size of visible part, 
step sizes etc...
Callbacks: onScrollStart onScroll onScrollFinished (or something like 
that)

So far, I've only listed plain read/write attributes, and callbacks 
(I'm in favour of allowing multiple callbacks).

We could add a whole lot of read-only attributes to each widget:

current size, minimum size, maximum size, (platform-specific) native 
handle, etc.

Were there any examples of write-only attributes, that can always be 
written, but never be read?

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)

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

On linked states:
a) I think that linked states and general state-change notification is 
outside the scope of the CGA.
b) Allowing linked states would require every state change to go 
through the CGA; it would be more difficult to map to the underlying 
backend library, in case the backend library changes some state "on 
it's own".

Cheers,

Wolfgang