Axel Simon wrote:
IMHO the classes should just reflect the object hierarchy. If we have e.g.
class Button b where... class ToggleButton b where... instance Button ToggleButton where...
Different toolkits have different hierarchies; e.g.: Motif: Core XmPrimitive XmLabel XmPushButton XmToggleButton XmArrowButton Athena: Core Simple Label Command (push-button) Repeater Toggle Qt: QWidget QFrame QLabel QButton QPushButton QRadioButton QCheckBox QToolButton Neither Motif nor Athena have separate classes for toggle buttons and radio buttons. Also, the situation for shell widgets (top-level windows) is a bit messy for Motif. Motif's shell classes are all subclasses of Xt's Shell class, which is a subclass of Xt's Composite class (containers). However, all of Motif's normal (non-shell) containers are subclasses of XmManager, while the shells aren't. For Xt (Motif/Athena), the class hierachy doesn't matter much to applications. Widgets are mostly accessed through generic Xt functions which operate upon any type of widget; e.g. setting/getting attribute values is done with XtSetValues/XtGetValues, which work on any widget (accessing an attribute which the widget doesn't possess is a run-time error). Widget classes may provide functions which only operate upon a specific type of widget (or a subclass), but such functions mostly exist only for the more complex widget classes (lists, text fields) which tend not to have subclasses. The class hierarchy is most relevant when implementing new widget classes; but that is likely to be well beyond the scope of the CGA. OTOH, the class hierarchy may be more of an issue for Qt (or MFC, if that is to be supported), but I'm not sufficiently familiar with Qt to be able to comment on that. Anyhow, to get back to the original issue, the key problem isn't the relative positions of push-buttons etc, but the fact that top-level windows are effectively subclasses of "widget" on some toolkits but not on others. If you're assuming that "widget" is the topmost level of the object hierarchy, this is likely to be a problem. -- Glynn Clements <glynn.clements@virgin.net>