Ned Konz wrote on Fri, 22 Apr 2005 12:02:51 -0700
> John Maloney certainly has the background to answer that, having done a couple 
> of papers (and his PhD thesis?) on constraint systems for GUIs.

Thanks for the book chapter reference! While looking for that I found
other interesting things, including a paper about Cassowary which is
available on the SqueakMap.

> I'm sure he can give more information on this, but when we talked about 
> general-purpose constraint systems for Squeak GUIs I got the impression that 
> he felt that the difficulty of communicating to the user just what was (or 
> wasn't) happening in the constraint system would get in the way of general 
> usefulness.

Interesting - the reason I wanted something like this was the idea that
constraints could be represented graphically in a way that would be easy
for the user to keep track of what was happening. We could have a set of
scaffolding objects whose visibility could be turned on or off as
needed.

> My impression has been that non-rigorous constraint systems (i.e. ones that 
> don't require all of their constraints to be satisfied all of the time) may 
> be helpful with GUI construction.

The Cassowary paper talked about several levels of constraint priorities
(or strengths) with the lowest ones being ignored as needed.

> However, we haven't fully attacked the simplest of layout schemes yet.

Tables are the case I am interested in. They actually aren't
complicated, but do need constraints in both X and Y directions at the
same time.

> For instance, the GTK+ scheme that uses horizontal or vertical containers with 
> different kinds of glue between their contents is at least easy to program 
> and explain.

This sounds similar to TeX and Morphic. It is nice to try to avoid
invisible objects in a layout scheme, but you often end up using a space
filling rectangle with the exact same color as the background to get
what you want and the effect might end up being very similar in
practice.

-- Jecel