haynes@DECWRL.DEC.COM (11/19/87)
In the next release, there is the notion of a "shell" widget. Top-level widgets are just shell widgets in the new scheme, and there can be many shell widgets. Other things shells are used for is pop-up menus, pull-down menus, "modal" dialog boxes (confirmation boxes, error boxes), and "modeless" dialog boxes otherwise known as independent top-level windows. The new spec should be available any day now. -- Charles
bobmi@hpcvlo.HP.COM (Bob Miller) (11/21/87)
We've had the new documentation for a few days, no bits yet, so all we have are the written descriptions. We will continue to read and get a better feel for the latest design, but, in the meantime: It was apparent from the Sept. 15th release that you would have to do something, like the shell widget feature, to support menus. However, if if my application simply wants 3 or 4 top level widgets, then the pop up calls look like a hack on the toolkit design. You might consider having "XtInitialize" simply initialize the resource database and create the *real* toplevel widget; its role in life would be to manage one or more shell widgets. A second call, "XtCreateTopLevel", accepts any class type and creates a widget of this type. It also automatically creates a shell widget and hangs the pair off of the *real* toplevel widget. Of course,"XtRealize" would have to work as expected (i.e., map the widget) on these toplevel widgets. Additionally, "XtDestroyWidget" could examine the invisible shells attached to the real toplevel widget and kill off any shell that didn't have a child. It's still a good idea to have separate calls for menu type widgets, they seem different enough from other widgets to merit their own calls. The point of doing all of this is to integrate the process of toplevel widget creation so it doesn't appear as a wart on the toolkit design. --Bob Miller HP X-ray Team