[ge-talk] A layout manager

[Christof Lutteroth]

Hi!

Paul van Nugteren wrote:
> There is something called liblayout made by Marco Nelissen, author of
> the IMHO excellent SoundPlay. Anyway I'd be interested to know what the
> differences are.
> 
>> I am a researcher at university, and my colleagues and me, we have done
>> some research on GUI layout. In particular, we are using linear
>> programming to calculate a layout that is specified in terms of linear
>> constraints, and higher-level constructs that are easier to use but can
>> be translated to linear constraints, such as spreadsheet-like layout.

I had a look at liblayout. I uses the containment hierarchy to arrange 
the controls in the GUI. That is, when programing the layout you have to 
  decompose the GUI into horizontally and vertically aligned subgroups 
of controls, which are nested hierarchically. (liblayout also supports 
layered groups, but this is a different story.) Most common layout 
managers (e.g. in Java and .NET) provide such layout constructs, and 
simple layouts can be programmed easily with them.

However, if the layouts are more complex, the containment hierarchy 
becomes deep and unwieldy. For example, consider a tabular layout. Say, 
you basically have a large table made up of cells, with controls in 
them, and now you want some controls to stretch over several adjacent 
rows and/or columns (like rowspan/colspan in HTML tables). This becomes 
increasingly complicated if you have to use the containment hierarchy. 
In fact, some such layouts cannot be created with only horizontal and 
vertically aligned groups of controls. Some other languages such as Java 
provide tabular layout containers such as GridBagLayout, but they still 
have issues (described in the paper) and are often quite hard to use.

Then, by recursively splitting up the layout into subgroups, it becomes 
very hard (or even impossible) to maintain constraints on controls in 
different subgroups, e.g. "button X in the top row of controls has the 
same width as button Y in the right column of the GUI". For many more 
complex layouts, this can be important, though, in order to give a GUI a 
really consistent look.

The linear programming approach (let's call it LP) does not need to use 
the containment hierarchy. Consider the whole GUI (or the part you want 
to lay out) as a grid of virtual vertical and horizontal lines; in the 
paper we call them x- and y-tabstops. Now, if you place a control into 
the GUI, you choose two x-tabstops for the left and right border of the 
control, and two y-tabstops for top and bottom. This rectangular region 
that contains the control is simply called an area. By doing so, you 
define the topology of the GUI, i.e. how the controls are aligned to one 
another, if a control is above/below/beside another etc.

Like in the liblayout, you can give each area a min and maxsize. 
Furtherore, you can specify how a control is aligned within its area 
(e.g. centered), margins (e.g. left margin) etc. The preferred size of a 
control is used as well, and you can specify how important the control 
is, i.e. the priority with which LP should try to give the control 
exactly its preferred size in case there is not enough or too much 
space. You can specify vales for the "reluctance" with which a control 
shrinks under its preferred size or grows over it. All these parameters 
can be hidden by letting LP assign sensible default values.

Now, once you have the topology all set up, you can add linear 
constraints to the layout specification, such as "column X should be 
twice as wide as column Y", or "button B should be at that exact 
position", or "row R should be 1cm/pixel/inch high" or "the aspect ratio 
of that panel should be 16:9". The LP solver will take care of those 
constraints and figure out the actual positions of the tabsops for you.

Conflicting constraints are not a problem because you can use soft 
constraints. I.e. You can say "I want that column to be 2cm wide, but 
only if its possible". The LP solver will try to fulfill the consraint 
as much as possible. You can prioritize constraints and tell the LP 
solver to give more important soft constraints precedence over less 
important ones.

Linear constraints have been used for solving really advanced layout 
problems such as tree and graph layout, so there is really a lot you can 
do. Of course, it's computationally more expensive than the simple 
container-based layout, but it's still fast. It allows developers to 
think about GUIs in a more geometrical manner, using invariants, instead 
of in terms of program code.

I hope this explains a bit (and was not too long to read for you). If 
you have any more questions, feel free to ask. If you are interested, 
you might want to look into the paper that I pointed out in the previous 
post. It would be really cool if Haiku had a layout system like that. It 
could be used alongside simpler constructs such as in liblayout.

Thanks for reading all this ;-)
Christof