[ge-talk] A layout manager

[Paul van Nugteren]

That was sure interesting, are there any benchmarks for the LP model
made?

On Sun, 26 Aug 2007 18:55:39 +1200, "Christof Lutteroth"
<lutteroth at cs.auckland.ac.nz> said:
> 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
> _______________________________________________
> glasselevator-talk mailing list
> glasselevator-talk at bug-br.org.br
> http://www.bug-br.org.br/mailman/listinfo/glasselevator-talk



http://www.fastmail.fm