bilbo.geoff@CS.UCLA.EDU (Geoff Kuenning) (11/03/87)
Okay, so I played around with the new toolkit and figured out how
to write a new widget. The new toolkit's pretty neat, though somewhat
limited by the realities of the C language. But now I want to put a bunch
of widgets (e.g., menus) around the borders of a window, the center of
which is graphics.
The proper solution to this, of course, is to write a handy composite
widget with geometry manager that magically handles the layout of the
various widgets exactly the way I want. This is nontrivial, of course.
A simpler solution is just to hardwire widget positions into some composite
widget that has a dumber geometry manager.
It though of using the Toplevel widget as the composite widget.
However, looking at the Toplevel widget's code shows that it can really
only handle a single subwidget, and it restricts that widget's geometry
fairly strongly.
I think that Toplevel should have a very cooperative geometry manager.
It should always endeavor to do exactly what a child asks with a minimum
of changes and a minimum of features. x/y/width/height requests should
be obeyed verbatim; the only special processing is that the Toplevel
window should dynamically expand and shrink to reflect the largest extents
of any of its children. This will make it easy to decorate a test
window with widgets during early development.
I have written a widget, called "Obedient," which implements such
a scheme. It's pretty easy. What do other people think about this
approach?
Geoff Kuenning geoff@lcc.ucla.edu geoff@ITcorp.comkit@athena.mit.edu (Chris D. Peterson) (11/06/87)
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