Zarządzanie geometrią (Xt)
Reguły X Toolkit określające, kto decyduje o rozmiarze i położeniu widżetu: dziecko prosi, rodzic decyduje, a powłoka na szczycie musi z kolei zapytać menedżera okien.
Widżet w Xt nie rysuje się, gdzie chce. Jego położenie i rozmiar należą do rodzica, widżetu Composite z metodą geometry_manager, a jeśli dziecko chce zmiany, prosi o nią przez XtMakeGeometryRequest. Odpowiedź brzmi XtGeometryYes, XtGeometryNo albo XtGeometryAlmost — „nie tak, ale może tak” — po czym dziecko może przyjąć kompromis lub odpuścić. Rodzic z kolei pyta dzieci o preferencje przez XtQueryGeometry i ustawia je przez XtConfigureWidget. Zarządzanie lub zwolnienie dziecka, XtManageChild i XtUnmanageChild, wywołuje change_managed i nowy układ. Widżety ograniczeń, takie jak XmForm z Motifa, dodają do każdego dziecka własne zasoby, zakotwiczenia, które określają, jak podąża za rodzicem przy zmianie rozmiaru.
Żądania, których rodzic nie może spełnić we własnych granicach, wędrują w górę, ogniwo po ogniwie, aż dotrą do powłoki, która tłumaczy je na XConfigureWindow i WM_NORMAL_HINTS i czeka na werdykt menedżera okien. Może on brzmieć: nie. Klasyczna pułapka to powłoka, która po zrealizowaniu odmawia powiększania, o ile nie ustawiono XtNallowShellResize, przez co okna dialogowe z dynamiczną zawartością bywają ucięte; druga to widżety odpowiadające sobie nawzajem Almost na Almost w nieskończoność. Mechanizm był ambitny jak na rok 1988 i tłumaczy, czemu programy Motif potrafiły reagować na rozmiar okna na długo przed innymi toolkitami — i czemu czasem nie reagowały.