Geometrieverwaltung (Xt)
Die Regeln des X Toolkit, wer über Größe und Position eines Widgets entscheidet: Das Kind fragt, das Elternteil entscheidet, und die Shell an der Spitze muss ihrerseits den Fenstermanager fragen.
Ein Widget in Xt zeichnet sich nicht einfach dorthin, wo es will. Position und Größe gehören seinem Elternteil, einem Composite-Widget mit der Methode geometry_manager, und wenn das Kind eine Änderung möchte, bittet es mit XtMakeGeometryRequest darum. Die Antwort lautet XtGeometryYes, XtGeometryNo oder XtGeometryAlmost – „nicht das, aber wie wäre es hiermit“ –, worauf das Kind den Kompromiss annehmen oder die Sache fallen lassen kann. Das Elternteil wiederum fragt seine Kinder mit XtQueryGeometry nach ihren Wünschen und platziert sie mit XtConfigureWidget. Das Verwalten oder Freigeben eines Kindes, XtManageChild und XtUnmanageChild, löst change_managed und ein neues Layout aus. Constraint-Widgets wie Motifs XmForm fügen jedem Kind eigene Ressourcen hinzu, die Attachments, die bestimmen, wie es beim Skalieren dem Elternteil folgt.
Anfragen, die ein Elternteil innerhalb seiner Grenzen nicht erfüllen kann, wandern Glied für Glied nach oben, bis sie die Shell erreichen, die sie in ein XConfigureWindow und WM_NORMAL_HINTS übersetzt und auf das Urteil des Fenstermanagers wartet. Das kann ein Nein sein. Die klassische Falle: Eine einmal realisierte Shell wächst nur, wenn XtNallowShellResize gesetzt ist, sodass Dialoge mit dynamischem Inhalt abgeschnitten werden; die andere sind Widgets, die einander in alle Ewigkeit mit Almost auf Almost antworten. Der Mechanismus war für 1988 ehrgeizig und erklärt, warum Motif-Programme auf Fenstergrößen reagieren konnten, lange bevor andere Toolkits es konnten – und warum sie es manchmal trotzdem nicht taten.