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
|
