Re: Flowing columned container

[Murray Cumming <murrayc murrayc com>]

On Fri, 2004-04-30 at 09:15, James Henstridge wrote:
> On 29/04/2004 11:50 PM, Murray Cumming wrote:
> 
> >I don't think that's the same thing. I think that's talking about
> >widgets whose width will increase when their height increases.
> >
> >I'm talking about a container that might have widgets arranged like
> >this:
> >
> >child1 child4 child7
> >child2 child5
> >child3 chidl6
> >
> >but when the container is made less high, they will be arranged like
> >this:
> >
> >child1 child3 child5 child7
> >child2 chidl4 child6
> >
> >Also, the minimum height would therefore be constrainted by the total
> >child widget height and the number of columns in the container.
> >  
> >
> What you have described is height for width geometry.  The widget gains 
> width as it loses height.

Actually, I would not like the widget to gain width as it loses height.
I would just like it to move some of its child widgets around. And if
there is not enough room for the child widgets then it should not allow
the height to be reduced any more.

Does it still seem like the same thing?

>   This sort of thing isn't really possible to 
> do right with GTK's current geometry management, where you specify a 
> required minimum height and width, then get allocated some space that is 
> usually at least that large.  To get your above example working, you'd 
> need another pass to calculate the required width once the widget knows 
> it's height.
> 
> About the only case where you can get height-for-width style geometry 
> management working without any modifications to GTK's current geometry 
> management is in a container widget that acts as a scrolled viewport.  
> The geometry of the container widget can be handled quite easily, and 
> the container can size the area inside the viewport however it wants.
> 
> James.
-- 
Murray Cumming
www.murrayc.com
murrayc murrayc com