Re: Minimum height for minimum width

[Tristan Van Berkom <tristanvb openismus com>]

On Tue, 2010-10-12 at 13:27 -0400, Havoc Pennington wrote:
> Hi,
> 
> On Tue, Oct 12, 2010 at 12:38 PM, Havoc Pennington <hp pobox com> wrote:
> > d) max size widget can do something useful with
> > e) size at which widget acts like expand=false (this is what I'd call
> > "max size" and I think it's a feature GTK doesn't have right now)
> 
> Trying to think about how these two are different, and not really
> getting anywhere. It seems like you'd never set the max size above the
> natural size.
> 
> So in the scrolled window case, to get the effect Matthias was going
> for, maybe the answer would just be to set the max size hint on the
> window to the natural size. The problem with that is basically
> maximization and fullscreen, i.e. that we don't really want a max size
> - it's better to add padding.
> 
> Conclusion perhaps, e) is not useful, user should always be able to
> resize "too high" and get extra padding in the layout, if they want.
> 
> The situation where it could make sense to add max_size to
> get_preferred_{width,height} might be if the natural size were defined
> as c) "a good size", then you'd also be able to use a separate "max
> useful size." For example then a box layout would first bring all
> children up to the good size; if still extra space, then bring them
> all up to max size; if still extra space, then start padding them.

Ah interesting, I suppose that when a label's xalign property is 
not FILL, it will cease unwrapping and giving away height once 
allocated any size greater than its natural width.

I suppose that's not really a problem though, the desired effect
of "align != FILL" needs only to be properly interpreted.