Museum

Home

Lab Overview

Retrotechnology Articles

Online Manuals

⇒ XtQueryGeom(3) — OSF1 1.0

Media Vault

Software Library

Restoration Projects

Artifacts Sought

Related Articles

XtMakeGeometryRequest(1)

Composite(3)

Core(3)

 

Name

XtQueryGeometry — query a child widget’s preferred geometry. 

Synopsis

XtGeometryResult XtQueryGeometry(w, intended, preferred_return)

Widget w;
XtWidgetGeometry ∗intended;
XtWidgetGeometry ∗preferred_return;

Arguments

wSpecifies the widget whose geometry preferences are being queried. 

intendedSpecifies any changes the parent plans to make to the child’s geometry, or NULL. 

preferred_return
Returns the child widget’s preferred geometry.

Description

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 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 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 and checks the query_geometry field of the specified widget’s class record.  If the widget’s query_geometry method is not NULL, XtQueryGeometry calls the query_geometry method and passes w, intended, and preferred_return as arguments.  If intended is NULL, XtQueryGeometry replaces it with a pointer to an XtWidgetGeometry structure with request_mode=0 before calling query_geometry. 

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 Xtquery_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 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 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 XtGeometryAlmost.  If the preferred geometry is identical to the current geometry, the query_geometry procedure should return XtGeometryNo. 

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 geometry_return
->request_mode and sets the corresponding fields in geometry_return to the current values from the widget instance.  If the request_mode field is not set to CWStackMode, 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 importantly, 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 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. 

Parents are expected to call XtQueryGeometry in their layout routine and wherever other information is significant after change_managed has been called.  The change_managed method 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 method. 

Structures

The return codes from geometry managers are:

typedef enum {
XtGeometryYes,/∗ Request accepted ∗/
XtGeometryNo,/∗ Request denied ∗/
XtGeometryAlmost,/∗ Request denied but willing to take reply ∗/
XtGeometryDone/∗ Request accepted and done ∗/
 } XtGeometryResult;

The XtWidgetGeometry structure is similar to but not identical to the corresponding Xlib 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;

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

#defineCWX(1<<0)
#defineCWY(1<<1)
#defineCWWidth(1<<2)
#defineCWHeight(1<<3)
#defineCWBorderWidth(1<<4)
#defineCWSibling(1<<5)
#defineCWStackMode(1<<6)

The Xt Intrinsics also support the following value:

#defineXtCWQueryOnly(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 Xlib XConfigureWindow function, uses request_mode to determine which fields in the XtWidgetGeometry structure you want to specify. 

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

#defineAbove0
#defineBelow1
#defineTopIf2
#defineBottomIf3
#defineOpposite4

The Intrinsics also support the following value:

#defineXtSMDontChange5

For precise definitions of Above, Below, TopIf, BottomIf, and Opposite, see the reference page for XConfigureWindow in Volume Two, Xlib Reference Manual.  XtSMDontChange indicates that the widget wants its current stacking order preserved. 

See Also

XtMakeGeometryRequest(1),
Composite(3), Core(3). 

Typewritten Software • bear@typewritten.org • Edmonds, WA 98026