Re: Extended Layout Summary

["Behdad Esfahbod" <behdad behdad org>]

On Nov 21, 2007 1:53 PM, Havoc Pennington <hp redhat com> wrote:
> Hi,
>
> Matthias Clasen wrote:
> > On Nov 20, 2007 8:45 PM, Behdad Esfahbod <behdad behdad org> wrote:
> >
> >>     a) Maximize number of children taking their natural size.
> >
> > I am not convinced this is always the best strategy. Doesn't this
> > encourage starving
> > one child in favour of the rest of the pack getting their natural size
> > ? If you really want
> > to be flexible in this, you probably need to go to a TeX-like glue
> > model and assign
> > stretchabilities and shrinkabilities to children.
> >
>
> The canonical example is an ellipsizable label, where the min size is
> something like the size of one letter plus "...", and the natural size
> is the entire label width (given the available height).
>
> So, if you have a box full of labels and get extra allocation above the
> minimum size, you want to first show all text in all labels (give
> everything its natural size) and then second add padding or spacing
> (give things more than their natural size).
>
> What you don't want to do is add padding or spacing, while some labels
> are still ellipsized.
>
> In the HippoCanvas comments I defined natural size as:
>
>    The natural width should be thought of as the width at which
>    alignment (HIPPO_ALIGNMENT_START etc.) makes no difference but at
>    which nothing will be chopped off or wrapped.
>
> That is, natural size is roughly defined as the size at which we show
> everything, but don't have any padding or spacing. It's "size that's
> more important than padding and spacing"
>
> Clearly this is something that should be crisply defined in the GTK docs
> when extended layout is added.
>
> Here is the comment from HippoCanvasBox on how its algorithm works; I am
> too lazy to follow Behdad's pseudocode to see if it is equivalent ;-)

You can't do that, that's what I did ;-).

> /*
>   If we have an allocation larger than our request (min width), we
>   distribute the space among children as follows:
>   1) for each child below natural width, bring it up to its natural width
>      a) count children with a request still below their natural width
>      b) find the child with the smallest needed expansion to reach
> natural width
>         and record this needed expansion
>      c) distribute among below-natural-width children the minimum of
>         (all space remaining to distribute) and
>         (smallest needed expansion times number of children to expand)
>      d) goto a) if children below natural width remain
>   2) if extra space still remains, divide it equally among each child
> with expand=true
>   In other words, children will always grow to their natural width
> whether they are expand=true
>   or not. Below-natural-size children always grow before expand=true
> children.

Yes I think they are equivalent.


>   Various optimizations are obviously possible here (keep track of flags
> for whether
>   we have any expandable / any natural!=minimum, for example).
>
>   The PACK_IF_FITS children are done in a second pass after other children,
>   the if_fits flag indicates which pass this is. If if_fits=TRUE we need
>   to skip if_fits children that did not fit.

Interesting.  Do you think that will be useful to add to Gtk+?

>
> Havoc


-- 
behdad
http://behdad.org/