Gerenciamento de geometria (Xt)
As regras do X Toolkit sobre quem decide o tamanho e a posição de um widget: o filho pede, o pai decide, e o shell no topo, por sua vez, precisa pedir ao gerenciador de janelas.
Um widget no Xt não se desenha onde bem entende. Sua posição e seu tamanho pertencem ao pai, um widget Composite com um método geometry_manager, e se o filho quer uma mudança, ele pede com XtMakeGeometryRequest. A resposta é XtGeometryYes, XtGeometryNo ou XtGeometryAlmost — "assim não, mas que tal assim" —, e depois disso o filho pode aceitar o meio-termo ou largar o assunto. O pai, por sua vez, pergunta aos filhos o que eles prefeririam com XtQueryGeometry e os posiciona com XtConfigureWidget. Gerenciar ou deixar de gerenciar um filho, XtManageChild e XtUnmanageChild, dispara change_managed e um novo layout. Widgets de restrição, como o XmForm do Motif, acrescentam recursos próprios a cada filho, as ancoragens, que governam como ele acompanha o pai ao redimensionar.
Pedidos que um pai não consegue atender dentro dos próprios limites sobem, elo por elo, até chegar ao shell, que os traduz num XConfigureWindow e em WM_NORMAL_HINTS e espera o veredicto do gerenciador de janelas. Pode ser não. A armadilha clássica é que um shell, depois de realizado, se recusa a crescer a menos que XtNallowShellResize esteja ligado, e então diálogos com conteúdo dinâmico ficam cortados; a outra é widgets respondendo Almost ao Almost um do outro por toda a eternidade. O mecanismo era ambicioso para 1988 e explica por que programas Motif conseguiam reagir ao tamanho da janela muito antes de outros toolkits — e por que às vezes não reagiam.