Wolfgang Thaller wrote:
*) We might need to add the parent widget as a required parameter to the constructor functions. Apple's "Carbon" API requires the toplevel window to be known at construction, the exact place in the window's widget hierarchy can be changed later. Widgets cannot be moved from one window to another. Win32 requires the parent widget to be specified at widget construction time, but it also provides a function called SetParent that's supposed to change a window's parent. Gtk doesn't seem to impose any restrictions, and neither does Apple's "Cocoa" API (formerly known as OpenStep). What about other potential backends?
Xt requires the widget's parent to be specified at creation time, and doesn't allow the parent to be changed thereafter.
*) Should windows really be widgets? At least they aren't on Mac OS, and making them look like widgets would be somehow artificial. Windows can't be added to any layout container, for example.
OTOH, Xt does treat top-level windows (shells) as widgets, and operations on shells are performed using the same mechanisms as for other widgets (i.e. XtAddCallback, Xt{Get,Set}Values etc). Also, shells have a parent; for "main" windows, the parent is normally the primary application shell (created by XtAppInitialize), while dialogs normally have their parent set to their "owner" window. Also, both Motif and Athena treat menu bars, menus and menu items as widgets (actually, menu items are usually "gadgets"; these don't have their own window, but otherwise behave like widgets), while other platforms may treat these specially. -- Glynn Clements <glynn.clements@virgin.net>