\&
.sp 1
.ce 3
\s+1\fBChapter 6\fP\s-1

\s+1\fBGeometry Management\fP\s-1
.sp 2
.nr H1 6
.nr H2 0
.nr H3 0
.nr H4 0
.nr H5 0
.LP
.XS
Chapter 6 \- Geometry Management 
.XE
.LP
.IN "geometry_manager procedure"
.IN "Geometry Management"
.IN "Configure Window"
A widget does not directly control its size and location;
rather, its parent is responsible for controlling its size and location.
Although the position of children is usually left up to their parent,
the widgets themselves often have the best idea of their optimal sizes
and, possibly, preferred locations.
.LP
To resolve physical layout conflicts between sibling widgets and between
a widget and its parent, the \*(xI provide the geometry management mechanism.
Almost all 
.PN Composite 
widgets have a geometry manager (geometry_manager field
in the widget class record) that is responsible for the size, position, and
stacking order of the widget's children.
The only exception are fixed boxes,
which create their children themselves and can ensure that
their children will never make a geometry request.
.NH 2
Initiating Geometry Changes
.LP
.XS
\*(SN Initiating Geometry Changes
.XE
Parents, children, and clients all initiate geometry changes differently.
Because a parent has absolute control of its children's geometry,
it changes the geometry directly by calling
.PN XtMoveWidget ,
.PN XtResizeWidget ,
or
.PN XtConfigureWidget .
A child must ask its parent for a geometry change by calling
.PN XtMakeGeometryRequest
or
.PN XtMakeResizeRequest
to convey its wishes to its parent.
An application or other client code initiates a geometry change by calling
.PN XtSetValues
on the appropriate geometry fields,
thereby giving the widget the opportunity to modify or reject the client
request before it gets propagated to the parent and the opportunity 
to respond appropriately to the parent's reply.
.LP
When a widget that needs to change its size, position, border width, 
or stacking depth asks its parent's geometry manager to make the desired 
changes,
the geometry manager can do one of the following:
.IP \(bu 5
Allow the request
.IP \(bu 5
Disallow the request
.IP \(bu 5
Suggest a compromise
.LP
When the geometry manager is asked to change the geometry of a child,
the geometry manager may also rearrange and resize any or all
of the other children that it controls.
The geometry manager can move children around freely using
.PN XtMoveWidget .
When it resizes a child (that is, changes width, height, or
border_width) other than the one making the request,
it should do so by calling
.PN XtResizeWidget .
It can simultaneously move and resize a child with a single call to
.PN XtConfigureWidget .
.LP
Often, geometry managers find that they can satisfy a request only if
they can reconfigure a widget that they are not in control of (in particular,
when the 
.PN Composite 
widget wants to change its own size).
In this case,
the geometry manager makes a request to its parent's geometry manager.
Geometry requests can cascade this way to arbitrary depth.
.LP
Because such cascaded arbitration of widget geometry can involve extended
negotiation,
windows are not actually allocated to widgets at application
startup until all widgets are satisfied with their geometry.
For further information,
see Sections 2.4 and 2.5.
.NT Notes
.IP 1. 5
The \*(xI treatment of stacking requests is deficient in several areas.
Stacking requests for unrealized widgets are granted but will have no effect.
In addition, there is no way to do an
.PN XtSetValues
that will generate a stacking geometry request.
.IP 2. 5
After a successful geometry request (one that returned
.PN XtGeometryYes ),
a widget does not know whether or not its resize procedure has been called.
Widgets should have resize procedures that can be called more than once
without ill effects.
.NE
.NH 2
General Geometry Manager Requests
.XS
\*(SN General Geometry Manager Requests
.XE
.LP
To make a general geometry manager request from a widget, use
.PN XtMakeGeometryRequest .
.IN "XtMakeGeometryRequest" "" "@DEF@"
.FD 0
XtGeometryResult XtMakeGeometryRequest(\fIw\fP, \fIrequest\fP, \
\fIreply_return\fP)
.br
      Widget \fIw\fP;
.br
      XtWidgetGeometry *\fIrequest\fP;
.br
      XtWidgetGeometry *\fIreply_return\fP;
.FN
.ds Wi that is making the request
.IP \fIw\fP 1i
Specifies the widget \*(Wi.
.IP \fIrequest\fP 1i
Specifies the desired widget geometry (size, position, border width,
and stacking order).
.IP \fIreply_return\fP 1i
Returns the allowed widget size or may be NULL
if the requesting widget is not interested in handling
.PN XtGeometryAlmost .
.LP
Depending on the condition,
.PN XtMakeGeometryRequest
performs the following:
.IP \(bu 5
If the widget is unmanaged or the widget's parent is not realized,
it makes the changes and returns
.PN XtGeometryYes .
.IP \(bu 5
If the parent is not a subclass of
.PN compositeWidgetClass 
or the parent's geometry_manager is NULL,
it issues an error.
.IP \(bu 5
If the widget's being_destroyed field is 
.PN True ,
it returns
.PN XtGeometryNo .
.IP \(bu 5
If the widget x, y, width, height and border_width fields are
all equal to the requested values,
it returns
.PN XtGeometryYes ;
otherwise, it calls the parent's geometry_manager procedure 
with the given parameters.
.IP \(bu 5
If the parent's geometry manager returns
.PN XtGeometryYes
and if
.PN XtCWQueryOnly
is not set in the request_mode
and if the widget is realized,
.PN XtMakeGeometryRequest
calls the 
.PN XConfigureWindow
Xlib function to reconfigure the widget's window (set its size, location, 
and stacking order as appropriate).
.IP \(bu 5
If the geometry manager returns
.PN XtGeometryDone ,
the change has been approved and actually has been done.
In this case,
.PN XtMakeGeometryRequest
does no configuring and returns 
.PN XtGeometryYes .
.PN XtMakeGeometryRequest
never returns
.PN XtGeometryDone .
.LP
Otherwise,
.PN XtMakeGeometryRequest
returns the resulting value from the parent's geometry manager.
.LP
Children of primitive widgets are always unmanaged; thus,
.PN XtMakeGeometryRequest
always returns
.PN XtGeometryYes
when called by a child of a primitive widget.
.LP
The return codes from geometry managers are:
.IN "XtGeometryResult"
.LP
.KS
.Ds 0
.TA .5i 1.75i
.ta .5i 1.75i
typedef enum _XtGeometryResult {
	XtGeometryYes,
	XtGeometryNo,
	XtGeometryAlmost,
	XtGeometryDone
} XtGeometryResult;
.De
.KE
.LP
The
.PN XtWidgetGeometry
structure is quite similar but not
identical to the corresponding Xlib structure:
.LP
.IN "XtGeometryMask"
.KS
.Ds 0
.TA .5i 3i
.ta .5i 3i
typedef unsigned long XtGeometryMask;

typedef struct {
	XtGeometryMask request_mode;
	Position x, y;
	Dimension width, height;
	Dimension border_width;
	Widget sibling;
	int stack_mode;
} XtWidgetGeometry;
.De
.KE
.LP
The request_mode definitions are from
.Pn < X11/X.h >:
.TS
lw(.5i) lw(2.5i) lw(.75i).
T{
#define
T}	T{
.PN CWX
T}	T{
(1<<0)
T}
T{
#define
T}	T{
.PN CWY
T}	T{
(1<<1)
T}
T{
#define
T}	T{
.PN CWWidth
T}	T{
(1<<2)
T}
T{
#define
T}	T{
.PN CWHeight
T}	T{
(1<<3)
T}
T{
#define
T}	T{
.PN CWBorderWidth
T}	T{
(1<<4)
T}
T{
#define
T}	T{
.PN CWSibling
T}	T{
(1<<5)
T}
T{
#define
T}	T{
.PN CWStackMode
T}	T{
(1<<6)
T}
.TE
.LP
The \*(xI also support the following value:
.TS
lw(.5i) lw(2.5i) lw(.75i).
T{
#define
T}	T{
.PN XtCWQueryOnly
T}	T{
(1<<7)
T}
.TE
.LP
.PN XtCWQueryOnly
indicates that the corresponding geometry request is only a query
as to what would happen if this geometry request were made
and that no widgets should actually be changed.
.LP
.PN XtMakeGeometryRequest ,
like the 
.PN XConfigureWindow 
Xlib function, uses request_mode to determine which fields in the
.PN XtWidgetGeometry
structure you want to specify.
.LP
The stack_mode definitions are from
.Pn < X11/X.h >:
.TS
lw(.5i) lw(2.5i) lw(.75i).
T{
#define
T}	T{
.PN Above
T}	T{
0
T}
T{
#define
T}	T{
.PN Below
T}	T{
1
T}
T{
#define
T}	T{
.PN TopIf
T}	T{
2
T}
T{
#define
T}	T{
.PN BottomIf
T}	T{
3
T}
T{
#define
T}	T{
.PN Opposite
T}	T{
4
T}
.TE
.LP
The \*(xI also support the following value:
.TS
lw(.5i) lw(2.5i) lw(.75i).
T{
#define
T}	T{
.PN XtSMDontChange
T}	T{
5
T}
.TE
.LP
For definition and behavior of
.PN Above ,
.PN Below ,
.PN TopIf ,
.PN BottomIf ,
and
.PN Opposite ,
see \fI\*(xL\fP.
.PN XtSMDontChange
indicates that the widget wants its current stacking order preserved.
.NH 2
Resize Requests
.XS
\*(SN Resize Requests
.XE
.LP
To make a simple resize request from a widget, you can use
.PN XtMakeResizeRequest 
as an alternative to
.PN XtMakeGeometryRequest .
.IN "XtMakeResizeRequest" "" "@DEF@"
.FD 0
XtGeometryResult XtMakeResizeRequest(\fIw\fP, \fIwidth\fP, \fIheight\fP, \
\fIwidth_return\fP, \fIheight_return\fP)
.br
      Widget \fIw\fP;
.br
      Dimension \fIwidth\fP, \fIheight\fP;
.br
      Dimension *\fIwidth_return\fP, *\fIheight_return\fP
.FN
.IP \fIw\fP 1i
Specifies the widget.
.IP \fIwidth\fP 1i
.br
.ns
.IP \fIheight\fP 1i
Specify the desired widget width and height.
.IP \fIwidth_return\fP 1i
.br
.ns
.IP \fIheight_return\fP 1i
Return the allowed widget width and height.
.LP
The
.PN XtMakeResizeRequest
function, a simple interface to
.PN XtMakeGeometryRequest ,
creates a
.PN XtWidgetGeometry
structure and specifies that width and height should change.
The geometry manager is free to modify any of the other window attributes
(position or stacking order) to satisfy the resize request.
If the return value is
.PN XtGeometryAlmost ,
width_return and height_return contain a compromise width and height.
If these are acceptable,
the widget should immediately make an
.PN XtMakeResizeRequest
and request that the compromise width and height be applied.
If the widget is not interested in
.PN XtGeometryAlmost
replies, 
it can pass NULL for width_return and height_return.
.NH 2
Potential Geometry Changes
.XS
\*(SN Potential Geometry Changes
.XE
.LP
Sometimes a geometry manager cannot respond to
a geometry request from a child without first making a geometry request
to the widget's own parent (the requestor's grandparent).
If the request to the grandparent would allow the parent to satisfy the
original request, 
the geometry manager can make the intermediate geometry request 
as if it were the originator.
On the other hand,
if the geometry manager already has determined that the original request
cannot be completely satisfied (for example, if it always denies
position changes),
it needs to tell the grandparent to respond to the intermediate request 
without actually changing the geometry
because it does not know if the child will accept the compromise.
To accomplish this, the geometry manager uses 
.PN XtCWQueryOnly
in the intermediate request.
.LP
When
.PN XtCWQueryOnly
is used, the geometry manager needs to cache
enough information to exactly reconstruct the intermediate request.
If the grandparent's response to the intermediate query was
.PN XtGeometryAlmost ,
the geometry manager needs to cache the entire
reply geometry in the event the child accepts the parent's compromise.
.LP
If the grandparent's response was
.PN XtGeometryAlmost ,
it may also be necessary to cache the entire reply geometry from
the grandparent when
.PN XtCWQueryOnly
is not used.
If the geometry manager is still able to satisfy the original request,
it may immediately accept the grandparent's compromise 
and then act on the child's request.
If the grandparent's compromise geometry is insufficient to allow 
the child's request and if the geometry manager is willing to offer
a different compromise to the child, 
the grandparent's compromise should not be accepted until the child 
has accepted the new compromise.
.LP
Note that a compromise geometry returned with
.PN XtGeometryAlmost
is guaranteed only for the next call to the same widget; 
therefore, a cache of size one is sufficient.
.NH 2
Child Geometry Management: the geometry_manager Procedure
.XS
\*(SN Child Geometry Management: the geometry_manager Procedure
.XE
.LP
The geometry_manager procedure pointer in a composite widget class is of type
.PN XtGeometryHandler :
.IN "XtGeometryHandler" "" "@DEF@"
.FD 0
typedef XtGeometryResult (*XtGeometryHandler)(Widget, XtWidgetGeometry *, \
XtWidgetGeometry *);
.br
      Widget \fIw\fP;
.br
      XtWidgetGeometry *\fIrequest\fP;
.br
      XtWidgetGeometry *\fIgeometry_return\fP;
.FN
.LP
A class can inherit its superclass's geometry manager during class
initialization.
.LP
A bit set to zero in the request's mask field means that the child widget
does not care about the value of the corresponding field.
Then, the geometry manager can change it as it wishes.
A bit set to 1 means that the child wants that geometry element changed
to the value in the corresponding field.
.LP
If the geometry manager can satisfy all changes requested 
and if 
.PN XtCWQueryOnly 
is not specified,
it updates the widget's x, y, width, height, and border_width values
appropriately.
Then, it returns
.PN XtGeometryYes ,
and the value of the geometry_return argument is undefined.
The widget's window is moved and resized automatically by
.PN XtMakeGeometryRequest .
.LP
Homogeneous composite widgets often find it convenient to treat the widget
making the request the same as any other widget, possibly reconfiguring
it as part of its layout process, unless 
.PN XtCWQueryOnly
is specified.
If it does this,
it should return
.PN XtGeometryDone
to inform
.PN XtMakeGeometryRequest
that it does not need to do the configuration itself.
.NT
To remain
compatible with layout techniques used in older widgets (before
.PN XtGeometryDone
was added to the \*(xI), a geometry manager should avoid using
.PN XtResizeWidget
or
.PN XtConfigureWidget
on the child making
the request as the layout process of the child may be in an
intermediate state.  A self-contained widget set may choose this
alternate geometry management scheme, however, provided that it
clearly warns widget developers of the compatibility consequences.
.NE
.LP
Although
.PN XtMakeGeometryRequest
resizes the widget's window
(if the geometry
manager returns
.PN XtGeometryYes ),
it does not call the widget class's resize procedure.
The requesting widget must perform whatever
resizing calculations are needed explicitly.
.LP
If the geometry manager chooses to disallow the request,
the widget cannot change its geometry.
The value of the geometry_return parameter is undefined,
and the geometry manager returns
.PN XtGeometryNo .
.LP
Sometimes the geometry manager cannot satisfy the request exactly,
but it may be able to satisfy a similar request.
That is,
it could satisfy only a subset of the requests (for example,
size but not position) or a lesser request
(for example, it cannot make the child as big as the
request but it can make the child bigger than its current size).
In such cases,
the geometry manager fills in geometry_return with the actual changes
it is willing to make, including an appropriate mask, and returns
.PN XtGeometryAlmost .
If a bit in geometry_return->request_mode is zero,
the geometry manager does not change the corresponding value
if the geometry_return is used immediately
in a new request.
If a bit is one,
the geometry manager does change that element to the corresponding
value in geometry_return.
More bits may be set in geometry_return than in the original request if
the geometry manager intends to change other fields should the
child accept the compromise.
.LP
When
.PN XtGeometryAlmost
is returned,
the widget must decide if the compromise suggested in geometry_return
is acceptable.
If it is, the widget must not change its geometry directly;
rather, it must make another call to
.PN XtMakeGeometryRequest .
.LP
If the next geometry request from this child uses the
geometry_return box filled in by an
.PN XtGeometryAlmost
return and if there have been no intervening geometry requests on
either its parent or any of its other children,
the geometry manager must grant the request, if possible.
That is, if the child asks immediately with the returned geometry,
it should get an answer of
.PN XtGeometryYes .
However, the user's window manager may affect the final outcome.
.LP
To return an
.PN XtGeometryYes ,
the geometry manager frequently rearranges the position of other managed 
children by calling
.PN XtMoveWidget .
However, a few geometry managers may sometimes change the
size of other managed children by calling
.PN XtResizeWidget
or
.PN XtConfigureWidget .
If
.PN XtCWQueryOnly
is specified,
the geometry manager must return how it would react to this geometry
request without actually moving or resizing any widgets.
.LP
Geometry managers must not assume that the request
and geometry_return arguments point to independent storage.
The caller is permitted to use the same field for both,
and the geometry manager must allocate its own temporary storage,
if necessary.
.NH 2
Widget Placement and Sizing
.XS
\*(SN Widget Placement and Sizing
.XE
.LP
To move a sibling widget of the child making the geometry request, use
.PN XtMoveWidget .
.IN "XtMoveWidget" "" "@DEF@"
.FD 0
void XtMoveWidget(\fIw\fP, \fIx\fP, \fIy\fP)
.br
      Widget \fIw\fP;
.br
      Position \fIx\fP;
.br
      Position \fIy\fP;
.FN
.IP \fIw\fP 1i
Specifies the widget.
.ds Nu new widget
.IP \fIx\fP 1i
.br
.ns
.IP \fIy\fP 1i
Specify the \*(Nu x and y coordinates.
.LP
The
.PN XtMoveWidget
function returns immediately if the specified geometry fields
are the same as the old values.
Otherwise,
.PN XtMoveWidget
writes the new x and y values into the widget 
and, if the widget is realized, issues an Xlib
.PN XMoveWindow
call on the widget's window.
.sp
.LP
To resize a sibling widget of the child making the geometry request, use
.PN XtResizeWidget .
.IN "XtResizeWidget" "" "@DEF@"
.FD 0
void XtResizeWidget(\fIw\fP, \fIwidth\fP, \fIheight\fP, \fIborder_width\fP)
.br
      Widget \fIw\fP;
.br
      Dimension \fIwidth\fP;
.br
      Dimension \fIheight\fP;
.br
      Dimension \fIborder_width\fP;
.FN
.IP \fIw\fP 1i
Specifies the widget.
.IP \fIwidth\fP 1i
.br
.ns
.IP \fIheight\fP 1i
.br
.ns
.IP \fIborder_width\fP 1i
Specify the new widget size.
.LP
The
.PN XtResizeWidget
function returns immediately if the specified geometry fields
are the same as the old values. 
Otherwise,
.PN XtResizeWidget
writes the new width, height, and border_width values into
the widget and, if the widget is realized, issues an
.PN XConfigureWindow
call on the widget's window.
.LP
If the new width or height are different from the old values,
.PN XtResizeWidget
calls the widget's resize procedure to notify it of the size change.
.sp
.LP
To move and resize the sibling widget of the child making the geometry request,
use
.PN XtConfigureWidget .
.IN "XtConfigureWidget" "" "@DEF@"
.FD 0
void XtConfigureWidget(\fIw\fP, \fIx\fP, \fIy\fP, \fIwidth\fP, \fIheight\fP, \
\fIborder_width\fP)
.br
      Widget \fIw\fP;
.br
      Position \fIx\fP;
.br
      Position \fIy\fP;
.br
      Dimension \fIwidth\fP;
.br
      Dimension \fIheight\fP;
.br
      Dimension \fIborder_width\fP;
.FN
.IP \fIw\fP 1i
Specifies the widget.
.ds Nu new widget
.IP \fIx\fP 1i
.br
.ns
.IP \fIy\fP 1i
Specify the \*(Nu x and y coordinates.
.IP \fIwidth\fP 1i
.br
.ns
.IP \fIheight\fP 1i
.br
.ns
.IP \fIborder_width\fP 1i
Specify the new widget size.
.LP
The
.PN XtConfigureWidget
function returns immediately if the specified geometry fields
are the same as the old values.
Otherwise,
.PN XtConfigureWidget
writes the new x, y, width, height, and border_width values 
into the widget and, if the widget is realized, makes an Xlib
.PN XConfigureWindow
call on the widget's window.
.LP
If either the new width or height is different from its old value,
.PN XtConfigureWidget
calls the widget's resize procedure to notify it of the size change;
otherwise, it simply returns.
.sp
.LP
To resize a child widget that already has the new values of its width,
height, and border width fields, use
.PN XtResizeWindow .
.IN "XtResizeWindow" "" "@DEF@"
.FD 0
void XtResizeWindow(\fIw\fP)
.br
      Widget \fIw\fP;
.FN
.IP \fIw\fP 1i
Specifies the widget.
.LP
The
.PN XtResizeWindow
function calls the 
.PN XConfigureWindow
Xlib function to make the window of the specified widget match its width,
height, and border width. 
This request is done unconditionally because there is no way to tell if these
values match the current values.
Note that the widget's resize procedure is not called.
.LP
There are very few times to use
.PN XtResizeWindow ;
instead, you should use
.PN XtResizeWidget .
.NH 2
Preferred Geometry
.XS
\*(SN Preferred Geometry
.XE
.LP
Some parents may be willing to adjust their layouts to accommodate the
preferred geometries of their children.
They can use
.PN XtQueryGeometry
to obtain the preferred geometry 
and, as they see fit, can use or ignore any portion of the response.
.sp
.LP
To query a child widget's preferred geometry, use
.PN XtQueryGeometry .
.IN "XtQueryGeometry" "" "@DEF@"
.FD 0
XtGeometryResult XtQueryGeometry(\fIw\fP, \fIintended\fP, \
\fIpreferred_return\fP)
.br
     Widget \fIw\fP\^;
.br
     XtWidgetGeometry *\fIintended\fP, *\fIpreferred_return\fP\^;
.FN
.IP \fIw\fP 1.1i
Specifies the widget.
.IP \fIintended\fP 1.1i
Specifies any changes the parent plans to make to the child's geometry or
NULL.
.IP \fIpreferred_return\fP 1.1i
Returns the child widget's preferred geometry.
.LP
To discover a child's preferred geometry,
the child's parent stores the new
geometry in the corresponding fields of
the intended structure, sets the corresponding bits in intended.request_mode,
and calls
.PN XtQueryGeometry .
The parent should set only those fields that are important to it so
the child can determine whether it may be able to attempt changes to
other fields.
.LP
.PN XtQueryGeometry
clears all bits in the preferred_return->request_mode and checks the
query_geometry field of the specified widget's class record.
If query_geometry is not NULL,
.PN XtQueryGeometry
calls the query_geometry procedure and passes as arguments the
specified widget, intended, and preferred_return structures.
If the intended argument is NULL,
.PN XtQueryGeometry
replaces it with a pointer to an
.PN XtWidgetGeometry
structure with request_mode=0 before calling query_geometry.
.NT
If
.PN XtQueryGeometry
is called from within a geometry_manager
procedure for the widget that issued
.PN XtMakeGeometryRequest
or
.PN XtMakeResizeRequest ,
the results
are not guaranteed to be consistent with the requested changes.  The
change request passed to the geometry manager takes precedence over
the preferred geometry.
.NE
.sp
.LP
The query_geometry procedure pointer is of type
.PN XtGeometryHandler .
.IN "query_geometry procedure" "" "@DEF@"
.FD 0
typedef XtGeometryResult (*XtGeometryHandler)(Widget, XtWidgetGeometry *, \
XtWidgetGeometry *);
.br
      Widget \fIw\fP;
.br
      XtWidgetGeometry *\fIrequest\fP;
.br
      XtWidgetGeometry *\fIgeometry_return\fP;
.FN
.IN "query_geometry procedure"
The query_geometry procedure is expected to examine the bits set in
request->request_mode, evaluate the preferred geometry of the widget,
and store the result in geometry_return
(setting the bits in geometry_return->request_mode corresponding
to those geometry fields that it cares about).
If the proposed geometry change is acceptable without modification,
the query_geometry procedure should return
.PN XtGeometryYes .
If at least one field in geometry_return
with a bit set in geometry_return->request_mode
is different
from the corresponding field in request
or if a bit was set in geometry_return->request_mode
that was not set in the request,
the query_geometry procedure should return
.PN XtGeometryAlmost .
If the preferred geometry is identical to the current geometry,
the query_geometry procedure should return
.PN XtGeometryNo .
.NT
The query_geometry procedure may assume
that no
.PN XtMakeResizeRequest
or
.PN XtMakeGeometryRequest
is in-progress
for the specified widget; that is, it is not required to construct
a reply consistent with the requested geometry if such a request
were actually outstanding.
.NE
.LP
After calling the query_geometry procedure
or if the query_geometry field is NULL,
.PN XtQueryGeometry
examines all the unset bits in geometry_return->request_mode
and sets the corresponding fields in geometry_return
to the current values from the widget instance.
If
.PN CWStackMode
is not set,
the stack_mode field is set to
.PN XtSMDontChange .
.PN XtQueryGeometry
returns the value returned by the query_geometry procedure or
.PN XtGeometryYes
if the query_geometry field is NULL.
.LP
Therefore, the caller can interpret a return of
.PN XtGeometryYes
as not needing to evaluate the contents of reply and, more importantly,
not needing to modify its layout plans.
A return of
.PN XtGeometryAlmost
means either that both the parent and the child expressed interest
in at least one common field and the child's preference does not match 
the parent's intentions or that the child expressed interest in a field that
the parent might need to consider.
A return value of
.PN XtGeometryNo
means that both the parent and the child expressed interest in a field and
that the child suggests that the field's current value is its preferred value.
In addition, whether or not the caller ignores the return value or the
reply mask, it is guaranteed that the reply structure contains complete
geometry information for the child.
.LP
Parents are expected to call
.PN XtQueryGeometry
in their layout routine and wherever other information is significant
after change_managed has been called.
The changed_managed procedure may assume that the child's current geometry
is its preferred geometry.
Thus, the child is still responsible for storing values
into its own geometry during its initialize procedure.
.NH 2
Size Change Management: the resize Procedure
.XS
\*(SN Size Change Management: the resize Procedure
.XE
.LP
A child can be resized by its parent at any time.
Widgets usually need to know when they have changed size
so that they can lay out their displayed data again to match the new size.
When a parent resizes a child, it calls
.PN XtResizeWidget ,
which updates the geometry fields in the widget,
configures the window if the widget is realized,
and calls the child's resize procedure to notify the child.
The resize procedure pointer is of type
.PN XtWidgetProc .
.IN "resize procedure" "" "@DEF@"
.\".FD 0
.\".so ./Xtsrc/XtWidProc.p
.\".FN
.\".IP \fIw\fP 1i
.\"Specifies the widget.
.LP
If a class need not recalculate anything when a widget is resized,
it can specify NULL for the resize field in its class record.
This is an unusual case and should occur only for widgets
with very trivial display semantics.
The resize procedure takes a widget as its only argument.
The x, y, width, height
and border_width fields of the widget contain the new values.
The resize procedure should recalculate the layout of internal data
as needed.
(For example, a centered Label in a window that changes size
should recalculate the starting position of the text.)
The widget must obey resize as a command and must not treat it as a request.
A widget must not issue an
.PN XtMakeGeometryRequest
or
.PN XtMakeResizeRequest
call from its resize procedure.
.bp
