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