Re: Baseline alignment ideas

[Alexander Larsson <alexl redhat com>]

On ons, 2013-02-27 at 17:47 +0900, Tristan wrote:

> Ah, I think I understand your question better now.
>
> Use a natural allocation process similar to
> gtk_distribute_natural_allocation():
> http://git.gnome.org/browse/gtk+/tree/gtk/gtksizerequest.c#n599
>
> Instead of looping over widget size requests, provide a normalized
> value for the minimum and natural requests "above" and "below" the
> children (after allocating the absolute minimum height).
>
>  o Start by giving equal minimum "above" height to all children and
>    equal minimum "below" height to all children

Well, this just means give each child their minimum height initially.

>  o Distribute extra allocated space above and below equally until
>    one of the sides ("above" or "below") reaches natural allocation

But, this is where I don't really follow. In practice all we have are
child widgets which we can ask for "what would the baseline be if you
had this height (and width, since its always fixed by now). From this
we want to decide the *total* height of each child.

How do we assign 5 pixels above the baseline based on this? All we can
do is give the child more total height (via gtk_widget_size_allocate),
we have in general no control of where that height will go. The child
might be expandable both above and below its baseline, but how can we
"tell" it to only grow above?

The only way I can see is this iterative algorithm. Its based on the
fact that as we add height to each child it may appear above or below
the baseline, and in the worst case of two children growing on different
sides the container height will grow by double of what we add to the
children.

So, we do something like:

1. allocate each child its own min height, calculate baseline and total
   height
2. calculate the missing height to the allocated height
3. assign half the missing height to each child, this will at
   *most* grow you to the allocated height.
4. Recalc the missing height, if > 0, goto 3

This will take log2 (assigned_height - min_height) steps and will result
in a state where there is at least one child we can't give more height
as that would make the total height larger than the allocation. 

However, there might still be some children that can safely expand. To
fill those we'd have to for each child try to grow it as much as
possible without affecting the total height. This can be done with a
similar loop, starting with adding MIN(space above widget, space below
widget) in a loop until this is 0. We then hit the top say, but then we
need another loop to see if giving more height means it extends towards
the bottom.

Each "try" here is a full size request, including w4h, h4w, children
with baselines, etc. This just strikes me as *way* too expensive.

A simpler approach would be to only ever look at the natural size
request for baseline aligned children, and always allocate size as per
this, never ever growing any children. Then we can top/bottom/center
align the whole group of baseline aligned children, but never FILL it.
This is trivial to calculate, but are there cases where this will not be
enough?