2. The set_values() Method

set_valuesmethodIf a value changed that should cause a layout change, go ahead and recompute the preferred size. Then, just set your width/height to the computed values: the Xt Intrinisics will automatically see a change made and call XtMakeGeometryRequest() on your behalf, so (ordinarily) don't do the layout step here.

If the request is granted, the Xt Intrinsics will automatically call your resize() method; that should be where the layout is done.

Rebuttal: There may be times where this isn't true. Some resources may require a Composite widget to re-layout. When doing so, there are a few warnings that should be noted.

• If the user set a resource that triggered a size adjustment, the resize request may not be honored by the parent. If it is not, and you re-layout, then be aware that you may have layed out to a geometry that isn't honored. This can cause (grossly understated) unexpected results. This case can (and does) happen in Label (and LabelGadget); that's why there is a call to the resize() method in expose() - to make sure the widget is displayed correctly. The same is true of CascadeButton (and CascadeButtonGadget).

• A superclass may have polluted the widget dimensions, or a resource that changed in a superclass may have altered the widget dimensions to cause a request that may not be honored. Laying out to this geometry may not be valid either.

Unfortunately, the intrinsics do not notify a widget if the resize request wasn't honored, so there's no way to do a proper job of it unless the expose() method calls the procedure that is responsible for the layout. Needless to say, this is not good for performance. One optimization that can be made is due to the nature of XtMakeGeometryRequest() (which will be discussed later): if the widget is not managed, or the parent isn't realized, then we can be sure that the resize request will be honored. In this case, we can blithely call our layout procedure and be sure that the request will be honored.