Gestión de geometría (Xt)
Las reglas del X Toolkit sobre quién decide el tamaño y la posición de un widget: el hijo pide, el padre decide, y el shell de arriba del todo tiene a su vez que preguntar al gestor de ventanas.
Un widget en Xt no se dibuja donde le apetece. Su posición y su tamaño pertenecen al padre, un widget Composite con el método geometry_manager, y si el hijo quiere cambiar algo lo pide con XtMakeGeometryRequest. La respuesta es XtGeometryYes, XtGeometryNo o XtGeometryAlmost ("eso no, pero qué tal esto"), tras lo cual el hijo acepta el compromiso o lo deja estar. El padre, por su parte, pregunta a sus hijos qué preferirían con XtQueryGeometry y los coloca con XtConfigureWidget. Gestionar o dejar de gestionar un hijo, XtManageChild y XtUnmanageChild, dispara change_managed y una nueva disposición. Los widgets Constraint, como XmForm de Motif, añaden además recursos propios a cada hijo, los attachments, que dictan cómo sigue al padre al cambiar de tamaño.
Las peticiones que un padre no puede satisfacer dentro de sus límites suben eslabón a eslabón hasta llegar al shell, que las traduce en un XConfigureWindow y en WM_NORMAL_HINTS y espera el veredicto del gestor de ventanas. Puede ser que no. La trampa clásica es que un shell, una vez realizado, se niega a crecer salvo que XtNallowShellResize esté activado, con lo que los diálogos de contenido dinámico salen recortados; la otra son widgets que responden Almost al Almost del otro por toda la eternidad. El mecanismo era ambicioso para 1988 y explica por qué los programas Motif reaccionaban al tamaño de la ventana mucho antes que otros toolkits, y por qué a veces no lo hacían.