_XmMakeGeometryRequestThe function prototype of this geometry negotiation convenience function is:
XtGeometryResult
_XmMakeGeometryRequest(Widget w, XtWidgetGeometry *desired);
This function is a wrapper around XtMakeGeometryRequest(). First, it asks the parent of the widget specified as the first parameter w for the new geometry (given in desired). If the parent's answer is XtGeometryAlmost, then _XmMakeGeometryRequest() takes a second round, asking the parent of w again, but this time using the geometry proposed by the parent. Then it returns.
Another programming mistake (introduced by Asente & Swick): given the Xt rule about XtGeometryAlmost, you could happily program a loop in which you keep calling XtMakeGeometryRequest() until the value is different from XtGeometryAlmost. The trouble is that this kind of a loop is only guaranteed to be finite if the parent widget(s) are bug-free. Need I say more?
_XmMakeGeometryRequest() detects this problem and is verbose about it: you'll see a warning, saying that a ``Parent refused resize request'' together with the name and class of the offending parent and the widget geometries in question. With LESSTIF, you might occasionally see this warning, because XmForm currently doesn't always grant a geometry that it just suggested...
If anybody wants a good exercise in understanding this document, she or he is invited to find this bug. Really. I'll only start tracking it myself when I have no serious bugs to attend to. A couple of beers (real or virtual? Ed.) can be had in Leuven, Belgium, by the first person to fix this.