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 <glynn.clements@virgin.net>