Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!bloom-beacon!athena.mit.edu!kit
From: kit@athena.mit.edu (Chris D. Peterson)
Newsgroups: comp.windows.x
Subject: Re: Toplevel widget's geometry manager
Message-ID: <1759@bloom-beacon.MIT.EDU>
Date: Fri, 6-Nov-87 14:05:50 EST
Article-I.D.: bloom-be.1759
Posted: Fri Nov  6 14:05:50 1987
Date-Received: Sun, 8-Nov-87 16:04:46 EST
References: <8711030020.AA11296@lanai.cs.ucla.edu>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: kit@athena.mit.edu (Chris D. Peterson)
Organization: Massachusetts Institute of Technology
Lines: 41

Keywords:toolkit toplevel


Funny you should come up with this now, I have been doing some fairly
heavy duty work with the new toolkit, I hope to have xman (does what
you unix types would guess) ready to put on the X11R2 tape, and have
been in close contact with Ralph Swick with the problems that I run
into (Alpha test what a concept), We spent about three hours last
week discussing what to do with the toplevel widget.  Here is what we
came up with:

	1. Toplevel currently is the only widget in existance that
           automatically manages its children, the idea behind this
           was that you would only want to put one child in it anyway
           (mostly because of its stupid geometry mananger), so why not
           manage it right away?  This is bad if you like to hard code in
	   the geometry management yourself, as I wanted to do with my
           popup menus.  Thus we are going to remove this auto management
           from the next release.

This allows Geoff to put a widget of the correct size for his
background into the top level widget, and manage it (thus setting the
size of toplevel) and then place his windows where he wants, in his code.  

NOTE: This method causes problems with the current (X11R1 tape) version of
      the toolkit as the realization proceedures in Intrinsic.c do not
      deal with unmanaged children correctly.  The change is in 
      XtRealizeWidget and sould be pretty obvious.

	2. Unmanaged widgets should be allowed to reasize themselves
           to whaever size they want, when they call XtMakeResizeRequest
	   for example.  They should get resized and always get a
	   XtGeometryYes response.  The parent may force a different size 
	   when they are later managed.

I guess the thing to remember is if there is something special you
want to do with your widgets you are not limited to the current
geometry managers, or to writing your own composite widget, you have
the option of leaving your widgets unmanaged.  XtManageChild is not a
mandatory action (or shouldn't be).

					Chris Peterson
					MIT - Project Athena
					kit@athena.mit.edu