Geometriebeheer (Xt)
De regels van de X Toolkit over wie de grootte en positie van een widget bepaalt: het kind vraagt, de ouder beslist, en de shell bovenaan moet op zijn beurt de vensterbeheerder om toestemming vragen.
Een widget in Xt tekent zich niet waar het zelf wil. Positie en grootte zijn van de ouder, een Composite-widget met een geometry_manager-methode, en wil het kind een wijziging, dan vraagt het erom met XtMakeGeometryRequest. Het antwoord is XtGeometryYes, XtGeometryNo of XtGeometryAlmost — ‘niet dat, maar wat dacht je hiervan’ — waarna het kind het compromis kan aanvaarden of de zaak laten rusten. De ouder vraagt op zijn beurt met XtQueryGeometry aan de kinderen wat zij zouden willen en plaatst ze met XtConfigureWidget. Een kind beheren of loslaten, XtManageChild en XtUnmanageChild, activeert change_managed en een nieuwe indeling. Constraint-widgets zoals XmForm van Motif voegen aan elk kind eigen resources toe, de bevestigingen, die bepalen hoe het de ouder volgt bij een groottewijziging.
Verzoeken die een ouder binnen zijn eigen grenzen niet kan inwilligen, reizen schakel na schakel omhoog tot ze de shell bereiken, die ze vertaalt naar een XConfigureWindow en WM_NORMAL_HINTS en op het oordeel van de vensterbeheerder wacht. Dat kan een nee zijn. De klassieke valkuil is dat een shell die eenmaal gerealiseerd is, weigert te groeien tenzij XtNallowShellResize is gezet, waardoor dialogen met dynamische inhoud worden afgeknipt; de andere is widgets die elkaars Almost tot in der eeuwigheid met Almost beantwoorden. Het mechanisme was ambitieus voor 1988 en verklaart waarom Motif-programma's lang vóór andere toolkits op de venstergrootte konden reageren — en waarom ze dat soms niet deden.