Gravity, control hierarchy usage
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
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