Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!hao!gatech!hubcap!ncrcae!ncr-sd!hp-sdd!hplabs!hp-pcd!hpcvlo!bobmi
From: bobmi@hpcvlo.HP.COM (Bob Miller)
Newsgroups: comp.windows.x
Subject: Re: Xtoolkit: Multiple "top-level" widgets in one application
Message-ID: <3940043@hpcvlo.HP.COM>
Date: Fri, 20-Nov-87 16:17:47 EST
Article-I.D.: hpcvlo.3940043
Posted: Fri Nov 20 16:17:47 1987
Date-Received: Mon, 23-Nov-87 03:47:56 EST
References: <8711182217.AA24914@vulcan.dec.com>
Organization: Hewlett-Packard Co., Corvallis, OR, USA
Lines: 27


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