[ge-talk] A layout manager

[Christof Lutteroth]

Fredrik Holmqvist wrote:
> It would be very interesting to try it. Up until now my favourite 
> layoutmanager (for java) has been https://designgridlayout.dev.java.net/

The LP model proposed by my colleagues and me is also based on the 
notion of a grid, but as far as I can see (from the few examples that I 
have read about the DesignGridLayout) it is more general and thus more 
powerful. The order in which you add controls is irrelevant, and it is 
possible to add controls that span not only several columns but also 
several rows, in addition to other things such as linear constraints and 
overlapping areas etc.

Let us consider the DesignGridLayout introductory example (a bit 
adapted), i.e. a grid with 6 buttons arranged in 2 columns and 2 rows:

DesignGridLayout layout = new DesignGridLayout( top );
layout.row().add( button1, button2 );
layout.row().add( button3, button4 );
layout.row().add( button5, button6 );


In the LP model you would do it like this:

Layout l = new Layout();
XTab x1 = new XTab();
YTab y1 = new YTab(), y2 = new YTab();
l.AddArea(l.Left, l.Top, x1, y1, button1);
l.AddArea(x1, l.Top, l.Right, y1, button2);
l.AddArea(l.Left, y1, x1, y2, button3);
l.AddArea(x1, y1, l.Right, y2, button4);
l.AddArea(l.Left, y2, x1, l.Bottom, button5);
l.AddArea(x1, y2, l.Right, l.Bottom, button6);

* XTabs and YTabs correspond to vertical and horizontal grid lines.
* l.Left, l.Top, l.Right, l.Bottom are predefined grid lines defining 
the bounds of the total layout area.
* each AddArea call defines the top, left, right and bottom gridline 
that define the bounds of a layout "area" (i.e. a rectangular part, 
usually  with a control in it)

So you could say that using DesignGridLayout is shorter for this 
example. But LP makes the definition of the areas more explicit and 
allows developers to set many more parameters in the AddArea method 
(such as margins, minsize, maxsize, alignment, etc). The actual 
dimensions of the areas are determined considering the preferred sizes 
of the buttons using linear optimization. That is, the dimensions are 
not just set as being all equal (or multiples of some size x) for the 
controls in a row.

Then, you can easily restructure the areas by merging them together. 
Say, we want to drop button6 and let button4 span vertically over two 
cells instead:

l.AddArea(l.Left, l.Top, x1, y1, button1);
l.AddArea(x1, l.Top, l.Right, y1, button2);
l.AddArea(l.Left, y1, x1, y2, button3);
l.AddArea(x1, y1, l.Right, l.Bottom, button4);
l.AddArea(l.Left, y2, x1, l.Bottom, button5);

Such changes can also be done dynamically, by changing the Area objects 
that are part of the layout. In one of my projects, I used the layout 
model to implement a fully dynamic tree view on complex structured data, 
changing synchronously with the data.

Regarding the performance, it really depends on the implementation. I 
have used a standard open-source solver, a very slow graphics renderer 
and have not used some algorithmical optimizations that could be used 
(besides code optimizations). The rendering time was in the order of 
milliseconds (about 1-50ms depending on the complexity of the layout) on 
a 3.4Ghz Pentium4. Re-rendering (e.g. after resizing) is generally much 
faster than the initial rendering due to incremental solving. Common 
layout specifications can be simplified upfront (what I didn't do), 
which makes it again faster. Other researchers have shown that also for 
slower hardware rendering times can be made to stay in the lower 
millisecond range, for small changes such as resizing usually below 
10ms. IMO this is well worth it, considering the expressiveness of 
linear constraints. Such a layout system could also be used for other 
applications such as print layout.

Cheers,
Christof