[GUI] More notes on the example implementation

[Glynn Clements]

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>