Re: Extended Layout Summary

[Vincent Untz <vuntz gnome org>]

Le mardi 20 novembre 2007, à 14:32 +0100, Mathias Hasselmann a écrit :
> Am Dienstag, den 20.11.2007, 14:10 +0100 schrieb Vincent Untz:
> > Hi Mathias,
> > 
> > Le mardi 20 novembre 2007, à 13:23 +0100, Mathias Hasselmann a écrit :
> > > The solution to this problem is simple: Interpret the result of the
> > > "size-request" signal as absolutely minimum size and introduce a new
> > > function for expressing the natural size of a widget.
> > 
> > Obviously something I should have asked during SoC... What about widgets
> > that may have more than one natural size? I'm thinking of the window
> > list here, which can group windows if necessary. Maybe that's the only
> > case where it would be useful, and if that's true, just forget this edge
> > case ;-)
> 
> Actually its a good question and answering it should be part of the
> extended layout docs, I guess.
> 
> The grouping feature of the window list actually is a fallback strategy,
> therefore the list should calculate its natural size by accumulating the
> natural sizes of its children in the ungrouped mode, were as it should
> accumulate minimum sizes in grouped mode for its own size-request.
> 
> Well, unless you highly prefer the grouped mode, and see the ungrouped
> mode as fallback. In that uncertain case you'd also use the grouped mode
> for calculating natural size.

The issue here is that the current way it works is that you can have
more than one natural sizes, depending on the number of groups you can
have. Eg:

[Epiphany][Epiphany[Epiphany][Terminal][Terminal]

can become:

[Epiphany ^][Terminal][Terminal]

or:

[Epiphany ^][Terminal ^]

So it's not a bit more complex than having only a minimum size and a
natural size.

(also, another thing here is that you hide/show some of the children
depending on the allocated size)

Vincent

-- 
Les gens heureux ne sont pas pressés.