4 ms·

An extension of the fixed layout would be the anchor+margin layout commonly used for game UIs, where each rect is defined by two opposing corners, each of those

An extension of the fixed layout would be the anchor+margin layout commonly used for game UIs, where each rect is defined by two opposing corners, each of those's axes defined as a % position within its parent, plus a fixed amount of pixels margin. In this regime, centering a 100px*50px element would be to make TopLeft=(50%-50px, 50%-25px) BottomRight=(50%+50px, 50%+25px)

wruza 5y ago
Another approach I remember uses a pre-sized template and attaches sides to other sides (unlike to parent sides only). E.g. you have a form of width 1000, then you drop button A at (10,10)-(495,50), button B at (505,10)-(990,50), and then connect A.right to follow B.left instead of Form.left (which is default). B.left is then told to be proportional to Form.right, and B.right follows Form.right. When parent resizes, margins and the spacing between them (10) are naturally maintained from the fact that they were 10px apart at design time, i.e. the layout stores their initial coords for using in calculations. A minor issue is that proportional at 505 is not equidistant to proportional at 500 (a true middle of the spacing) at all times, but you just ignore that. All the rules are of the form: A.side {follows|proportional} B.side By default *.side follows Form.left (or top) And few shorthands, e.g. “A expands hotizontally” means A.right follows Parent.right, etc. It is actually a dumbed down version of a constraints model and is a subset of it, though it looks and feels more like boxing or alignment models. It was used in pre-constraints apple toolkits and few other products. The main difference is that these follow/proportional constraints are tree-like (cycles forbidden), when true constraint-based layout is a linear problem that requires a special solver optimized for ui-related [in]equality patterns to update in realtime.

wruza 5y ago

Another approach I remember uses a pre-sized template and attaches sides to other sides (unlike to parent sides only). E.g. you have a form of width 1000, then you drop button A at (10,10)-(495,50), button B at (505,10)-(990,50), and then connect A.right to follow B.left instead of Form.left (which is default). B.left is then told to be proportional to Form.right, and B.right follows Form.right. When parent resizes, margins and the spacing between them (10) are naturally maintained from the fact that they were 10px apart at design time, i.e. the layout stores their initial coords for using in calculations. A minor issue is that proportional at 505 is not equidistant to proportional at 500 (a true middle of the spacing) at all times, but you just ignore that. All the rules are of the form: A.side {follows|proportional} B.side By default *.side follows Form.left (or top) And few shorthands, e.g. “A expands hotizontally” means A.right follows Parent.right, etc. It is actually a dumbed down version of a constraints model and is a subset of it, though it looks and feels more like boxing or alignment models. It was used in pre-constraints apple toolkits and few other products. The main difference is that these follow/proportional constraints are tree-like (cycles forbidden), when true constraint-based layout is a linear problem that requires a special solver optimized for ui-related [in]equality patterns to update in realtime.