Gravity, control hierarchy usage

Joachim Durchholz <>
Mon Jan 19 19:43:49 CET 2004

Peter-Henry Mander wrote:

> And I've successfully prodded the WinGravity property to enable rudimentary placement management on resizing the parent,

A note to library designers: X gravity sucks.
It is far too limited to be useful in good designs.
The minimum resize model would be something along the lines of Tk: it 
strikes a pretty useful balance between generality and ease of 
For something entirely different, one could do it in a constraint-based 
fashion: allow programmers to specify constraints, and plop in a 
constraint solver (there are several open-source ones available, I can 
dig one up if there's interest).

The downside with the Tk approach is that it uses the control hierarchy 
to express visual constraints. These often go with the logical 
hierarchy, but not always - and things become pretty ugly if you have to 
work against it.

In other words: if you have a control hierarchy, you can use it only for 
*one* aspect: EITHER layout, OR to determine control order (there's 
often a natural order in which the end user will visit fields, and it's 
often nice to support this by automatically placing the keyboard focus 
to the next field at appropriate triggers), OR to inherit default 
property settings (such as background color or visibility).
All GUI toolkits that I have seen which tried to hook more than one 
aspect into control hierarchy made life quite miserable for the 
application programmer.

That's why I vastly prefer the constraint-based approach - but I'm well 
aware that this is a lot of code to write. At this stage of development, 
I'd use a simple hand-crafted constraint engine.

Currently looking for a new job.

More information about the erlang-questions mailing list