Sven Panne wrote:
[...] This raises the problem: what if I have also "instance Positioned Window"? Well, this problem has many solutions, the simplest of wich is *not* to have statically read-only attributes. I would rather try other solutions, however they might complicate the class and type hierarchy.
What do you all think about this?
I think that the distinction (read-only, write-only, read-write) is very important for a good API design:
Reminder: under Xt, an attribute has three such "flags":
[C] Can be set when the widget is created (XtCreateWidget etc).
[S] Can be set after the widget is created (XtSetValues etc).
[G] Can be retrieved (XtGetValues etc).
These are all independent, although some combinations are more common
than others:
+ Attributes tend to be CSG unless there is a reason to the contrary.
+ Callback lists are invariably C; once the widget is created, you
have to use Xt{Add,Remove}Callback rather than replacing the entire
list.
+ C without S is quite common; attributes which dictate a specific
"role" for a widget (e.g. XmNrowColumnType) usually can't be changed.
+ S without C typically corresponds to attributes types for which a
value can't reasonably be constructed before the widget has been
created. E.g. for compound widgets (e.g. OK/Cancel dialogs), the
attributes which specify the child widgets (e.g. the OK/Cancel
buttons) are SG.
+ The absence of G is not uncommon; this typically means that the
resource value is converted to an internal form in a way that can't
readily be reversed.
+ Just G (i.e. read-only) is common for values which are computed
rather than stored (e.g. XmNancestorSensitive).
--
Glynn Clements