State, Attributes and Some basic widgets

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