Chapter 6

Geometry Management

A widget does not directly control its size and location; rather, its parent is responsible for controlling them. 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.

To resolve physical layout conflicts between sibling widgets and between a widget and its parent, the Intrinsics provide the geometry management mechanism. Almost all composite widgets have a geometry manager specified in the 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 is fixed boxes, which create their children themselves and can ensure that their children will never make a geometry request.

Parents, children, and clients each initiate geometry changes differently. Because a parent has absolute control of its children's geometry, it changes the geometry directly by calling XtMoveWidget, XtResizeWidget, or XtConfigureWidget. A child must ask its parent for a geometry change by calling XtMakeGeometryRequest or XtMakeResizeRequest. An application or other client code initiates a geometry change by calling 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.

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 allow the request, disallow the request, or suggest a compromise.

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 XtMoveWidget. When it resizes a child (that is, changes the width, height, or border width) other than the one making the request, it should do so by calling XtResizeWidget. The requesting child may be given special treatment; see Section 6.5. It can simultaneously move and resize a child with a single call to XtConfigureWidget.

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, the composite widget may want 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.

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; see Sections 2.5 and 2.6.

When making a geometry request, the child specifies an XtWidgetGeometry structure.

typedef unsigned long XtGeometryMask;

typedef struct {

XtGeometryMask request_mode;
Position x, y;
Dimension width, height;
Dimension border_width;
Widget sibling; int stack_mode;

} XtWidgetGeometry;

To make a general geometry manager request from a widget, use XtMakeGeometryRequest.

XtGeometryResult XtMakeGeometryRequest(w, request, reply_return)

Widget w;
XtWidgetGeometry *request;
XtWidgetGeometry *reply_return;

w	Specifies the widget making the request. Must be of class RectObj or any subclass thereof.
request	Specifies the desired widget geometry (size, position, border width, and stacking order).
reply_return	Returns the allowed widget size, or may be NULL if the requesting widget is not interested in handling XtGeometryAlmost.

Depending on the condition, XtMakeGeometryRequest performs the following:

• If the widget is unmanaged or the widget's parent is not realized, it makes the changes and returns XtGeometryYes.

• If the parent's class is not a subclass of compositeWidgetClass or the parent's geometry manager field is NULL, it issues an error.

• If the widget's being_destroyed field is True, it returns XtGeometryNo.

• If the widget x, y, width, height and, border width fields are all equal to the requested values, it returns XtGeometryYes; otherwise, it calls the parent's geometry manager procedure with the given parameters.

• If the parent's geometry manager returns XtGeometryYes and if XtCWQueryOnly is not set in request->request_mode and if the widget is realized, XtMakeGeometryRequest calls the XConfigureWindow Xlib function to reconfigure the widget's window (set its size, location, and stacking order as appropriate).

• If the geometry manager returns XtGeometryDone, the change has been approved and actually has been done. In this case, XtMakeGeometryRequest does no configuring and returns XtGeometryYes. XtMakeGeometryRequest never returns XtGeometryDone.

• Otherwise, XtMakeGeometryRequest just returns the resulting value from the parent's geometry manager.

Children of primitive widgets are always unmanaged; therefore, XtMakeGeometryRequest always returns XtGeometryYes when called by a child of a primitive widget.

The return codes from geometry managers are

typedef enum {

XtGeometryYes,
XtGeometryNo,
XtGeometryAlmost,
XtGeome try Done

} XtGeometryResult;

The request_mode definitions are from <X11/X.h>.

#define	CWX	(1<<0)
#define	CWY	(1<<1)
#define	CWWidth	(1<<2)
#define	CWHeight	(1<<3)
#define	CWBorderWidth	(1<<4)
#define	CWSibling	(1<<5)
#define	CWStackMode	(1<<6)

The Intrinsics also support the following value.

#define

XtCWQueryOnly

(1<<7)

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.

XtMakeGeometryRequest, like the XConfigureWindow Xlib function, uses request mode to determine which fields in the XtWidgetGeometry structure the caller wants to specify.

The stack_mode definitions are from <X11/X.h>:

#define	Above	0
#define	Below	1
#define	Topic	2
#define	BottomIf	3
#define	Opposite	4

The Intrinsics also support the following value.

#define

XtSMDontChange

5

For definition and behavior of Above, Below, TopIf, BottomIf, and Opposite, see Section 3.7 in Xlib - C Language X Interface. XtSMDontChange indicates that the widget wants its current stacking order preserved.

To make a simple resize request from a widget, you can use XtMakeResizeRequest as an alternative to XtMakeGeometryRequest.

XtGeometryResult XtMakeResizeRequest(w, width, height, width return, height return)

Widget w;
Dimension width, height;
Dimension *width return, *height return;

w	Specifies the widget making the request. Must be of class RectObj or any subclass thereof.
width
height	Specify the desired widget width and height.
width_return
height return	Return the allowed widget width and height.

The XtMakeResizeRequest function, a simple interface to XtMakeGeometryRequest, creates an XtWidgetGeometry structure and specifies that width and height should change by setting request_mode to CWWidth | CWHeight. 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 XtGeometryAlmost, width_ return and height_return contain a compromise width and height. If these are acceptable, the widget should immediately call XtMakeResizeRequest again and request that the compromise width and height be applied. If the widget is not interested in XtGeometryAlmost replies, it can pass NULL for width_return and height_ return.

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 original 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 XtCWQueryOnly in the intermediate request.

When 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 XtGeometryAlmost, the geometry manager needs to cache the entire reply geometry in the event the child accepts the parent's compromise.

If the grandparent's response was XtGeometryAlmost, it may also be necessary to cache the entire reply geometry from the grandparent when 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.

Note that a compromise geometry returned with XtGeometryAlmost is guaranteed only for the next call to the same widget; therefore, a cache of size 1 is sufficient.

The geometry_manager procedure pointer in a composite widget class is of type XtGeometryHandler .

typedef XtGeometryResult (*XtGeometryHandler)(Widget, XtWidgetGeometry*, XtWidgetGeometry*);

Widget w;
XtWidgetGeometry *request;
o XtWidgetGeometry *geometry return;

w	Passes the widget making the request.
Request	Passes the new geometry the child desires.
geometry_return	Passes a geometry structure in which the geometry manager may store a compromise.

A class can inherit its superclass's geometry manager during class initialization.

A bit set to zero in the request's request mode field means that the child widget does not care about the value of the corresponding field, so the geometry manager can change this field as it wishes. A bit set to 1 means that the child wants that geometry element set to the value in the corresponding field.

If the geometry manager can satisfy all changes requested and if XtCWQueryOnly is not specified, it updates the widget's x, y, width, height, and border width fields appropriately. Then, it returns XtGeometryYes, and the values pointed to by the geometry return argument are undefined. The widget's window is moved and resized automatically by XtMakeGeometryRequest.

Homogeneous composite widgets often find it convenient to treat the widget making the request the same as any other widget, including reconfiguring it using XtConfigureWidget or XtResizeWidget as part of its layout process, unless XtCWQueryOnly is specified. If it does this, it should return XtGeometryDone to inform XtMakeGeometryRequest that it does not need to do the configuration itself.

NOTE

To remain compatible with layout techniques used in older widgets (before XtGeometryDone was added to the Intrinsics), a geometry manager should avoid using XtResizeWidget orXtConfigureWidget on the child making the request because the layout process of the child may be in an intermediate state in which it is not prepared to handle a call to its resize procedure. A self-contained widget set may choose this alternative geometry management scheme, however, provided that it clearly warns widget developers of the compatibility consequences.

Although XtMakeGeometryRequest resizes the widget's window (if the geometry manager returns XtGeometryYes), it does not call the widget class's resize procedure. The requesting widget must perform whatever resizing calculations are needed explicitly.

If the geometry manager disallows the request, the widget cannot change its geometry. The values pointed to by geometry_return are undefined, and the geometry manager returns XtGeometryNo.

Sometimes the geometry manager cannot satisfy the request exactly but 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 the structure pointed to by geometry_ return with the actual changes it is willing to make, including an appropriate request_mode mask, and returns XtGeometryAlmost. If a bit in geometry return->request_ mode is zero, the geometry manager agrees not to change the corresponding value if geometry_return is used immediately in a new request. If a bit is 1, the geometry manager does change that element to the corresponding value in geometry_return. More bits may be set in geometry_retun->request_mode than in the original request if the geometry manager intends to change other fields should the child accept the compromise.

When 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 XtMakeGeometryRequest.

If the next geometry request from this child uses the geometry return values filled in by the geometry manager with an 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 XtGeometryYes. However, dynamic behavior in the user's window manager may affect the final outcome.

To return XtGeometryYes, the geometry manager frequently rearranges the position of other managed children by calling XtMoveWidget. However, a few geometry managers may sometimes change the size of other managed children by calling XtResizeWidget or XtConfigureWidget. If XtCWQueryOnly is specified, the geometry manager must return data describing how it would react to this geometry request without actually moving or resizing any widgets.

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.

Home

---

6.6. Widget Placement and Sizing

To move a sibling widget of the child making the geometry request, the parent uses XtMoveWidget.

void XtMoveWidget(w, x, y)

Widget w;
Position x;
Position y;

w	Specifies the widget. Must be of class RectObj or any subclass thereof.
x
y	Specify the new widget x and y coordinates.

The XtMoveWidget function returns immediately if the specified geometry fields are the same as the old values. Otherwise, XtMoveWidget writes the new x and y values into the object and, if the object is a widget and is realized, issues an Xlib XMoveWindow call on the widget's window.

To resize a sibling widget of the child making the geometry request, the parent uses XtResizeWidget .

void XtResizeWidget(w, width, height, border_width)

Widget w;
Dimension width;
Dimension height;
Dimension border_width;

w	Specifies the widget. Must be of class RectObj or any subclass thereof.
width
height
border_width	Specify the new widget size.

The XtResizeWidget function returns immediately if the specified geometry fields are the same as the old values. Otherwise, XtResizeWidget writes the new width, height, and border width values into the object and, if the object is a widget and is realized, issues an XConfigureWindow call on the widget's window.

If the new width or height is different from the old values, XtResizeWidget calls the object's resize procedure to notify it of the size change.

To move and resize the sibling widget of the child making the geometry request, the parent uses XtConfigureWidget .

void XtConfigureWidget(w, x, y, width, height, border_width)

Widget w;
Position x;
Position y;
Dimension width;
Dimension height;
Dimension border_width;

w	Specifies the widget. Must be of class RectObj or any subclass thereof.
x
y	Specify the new widget x and y coordinates.
width
height
border width	Specify the new widget size.

The XtConfigureWidget function returns immediately if the specified new geometry fields are all equal to the current values. Otherwise, XtConfigureWidget writes the new x, y, width, height, and border_width values into the object and, if the object is a widget and is realized, makes an Xlib XConfigureWindow call on the widget's window.

If the new width or height is different from its old value, XtConfigureWidget calls the object's resize procedure to notify it of the size change; otherwise, it simply returns.

To resize a child widget that already has the new values of its width, height, and border width, the parent uses XtResizeWindow.

void XtResizeWindow(w)

Widget w;

w	Specifies the widget. Must be of class Core or any subclass thereof.

The XtResizeWindow function calls the 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 inexpensive way to tell if these values match the current values. Note that the widget's resize procedure is not called.

There are very few times to use XtResizeWindow; instead, the parent should use XtResizeWidget .

Home

---

6.7. Preferred Geometry

Some parents may be willing to adjust their layouts to accommodate the preferred geometries of their children. They can use XtQueryGeometry to obtain the preferred geometry and, as they see fit, can use or ignore any portion of the response.

To query a child widget's preferred geometry, use XtQueryGeometry.

XtGeometryResult XtQueryGeometry(w, intended, preferred_return)

Widget w;
XtWidgetGeometry *intended, *preferred return;

w	Specifies the widget. Must be of class RectObj or any subclass thereof.
intended	Specifies the new geometry the parent plans to give to the child, or NULL.
Preferred_return	Returns the child widget's preferred geometry.

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 XtQueryGeometry. The parent should set only those fields that are important to it so that the child can determine whether it may be able to attempt changes to other fields.

XtQueryGeometry clears all bits in the preferred_return->request_mode field and checks the query_geometry field of the specified widget's class record. If query_geometry is not NULL, XtQueryGeometry calls the query_geometry procedure and passes as arguments the specified widget, intended, and preferred_return structures. If the intended argument is NULL, XtQueryGeometry replaces it with a pointer to an XtWidgetGeometry structure with request_mode equal to zero before calling the query_geometry procedure.

NOTE

If XtQueryGeometry is called from within a geometry_manager procedure for the widget that issued XtMakeGeometryRequest or 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.

The query_geometry procedure pointer is of type XtGeometryHandler.

typedef XtGeometryResult (*XtGeometryHandler)(Widget, XtWidgetGeometry*, XtWidgetGeometry*);

Widget w;
XtWidgetGeometry *request;
XtWidgetGeometry *preferred_return;

w	Passes the child widget whose preferred geometry is required.
Request	Passes the geometry changes which the parent plans to make.
preferred_return	Passes a structure in which the child returns its preferred geometry.

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 preferred_return (setting the bits in preferred_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 XtGeometryYes. If at least one field in preferred_return with a bit set in preferred_return->request mode is different from the corresponding field in request or if a bit was set in preferred_return->request_mode that was not set in the request, the query_geometry procedure should return XtGeometryAlmost. If the preferred geometry is identical to the current geometry, the query_geometry procedure should return XtGeometryNo.

NOTE

The query_geometry procedure may assume that no XtMakeResizeRequest or 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.

After calling the query_geometry procedure or if the query_geometry field is NULL, XtQueryGeometry examines all the unset bits in preferred_return->request_mode and sets the corresponding fields in preferred_return to the current values from the widget instance. If CWStackMode is not set, the stack_mode field is set to XtSMDontChange. XtQueryGeometry returns the value returned by the query_geometry procedure or XtGeometryYes if the query_geometry field is NULL.

Therefore, the caller can interpret a return of XtGeometryYes as not needing to evaluate the contents of the reply and, more important, not needing to modify its layout plans. A return of 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 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 in the widget instance is its preferred value. In addition, whether or not the caller ignores the return value or the reply mask, it is guaranteed that the preferred_return structure contains complete geometry information for the child.

Parents are expected to call XtQueryGeometry in their layout routine and wherever else the information is significant after change_managed has been called. The first time it is invoked, 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.

Home

---

6.8. Size Change Management: the resize Procedure

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 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 XtWidgetProc.

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 XtMakeGeometryRequest or XtMakeResizeRequest call from its resize procedure.

Home

Contents

Previous Chapter

Next Chapter