Re: Extended Layout

[Owen Taylor <otaylor redhat com>]

On Mon, 2010-04-12 at 15:16 -0400, Tristan Van Berkom wrote:

> ------------- Problem --------------
> 
> There is another problem I cant seem to figure out at this point
> and it would be great if someone with prior experience in this area
> could explain.
> 
> The problem in a phrase is this:
>   How do you get the collective minimum and natural height for all
>   the children in a GtkHBox given a width for the box ?
>
> In UI terms, A label will unwrap and request less height inside a
> VBox - pretty easy. But a Label with a Button inside an HBox
> placed in a GtkVBox will unwrap when widened; the HBox will not
> request any less height for that.

I think there's a reasonable meaningful implementation of
height-for-width for a horizontal box - see:

http://git.gnome.org/browse/hippo-canvas/tree/common/hippo/hippo-canvas-box.c

for an implementation. I forget the exact details, but I think the basic
idea is just to do the expand/fill calculations based on the minimum and
natural widths of the children. Then based upon the computed child
sizes, compute minimum and natural heights for the children.

This will certainly work fine in simple situations - e.g. one child is
fixed with and set not to expand, and another child is a wrapped label.

That's for height-for-width children inside a height-for-width
horizontal box. HippoCanvas just had height-for-width, and that made
things a lot simpler to think about and to get completely right. 
(My impression of the layout containers in Clutter 1.2, in MX, in ST, is
that width-for-height is honored more in name than in actuality.)

Once you get collections of height-for-width and width-for-height
widgets mixed together it gets really, really hard to think about. My
general advice to try and keep things sane is that a container should
say:

 If I was called in height-for-width mode, I will size negotiate all my
 children in height-for-width mode as well.

And vice-versa. 

Then if a widget can't do the requested negotiation mode, then it should
just do the simple thing. If I ask for the natural height of a GtkLabel
for a width of -1, it should tell me the height it would have for its
natural width without wrapping. And if I ask for the natural width of a
label for a specified height h, it should ignore h, and just tell me its
natural width without wrapping.

[ 
* Actually, a bit better than this is to honor
gtk_widget_set_size_request() values if provided in preference to the
natural width.

* It's possible a widget should declare whether it implements
height-for-width or width-for-height or both, and GTK+ should take care
of falling back to the simple behavior for unimplemented modes.
]

> I wrote an algorithm for this but its expensive; the HBox has
> to guess some heights and query all children if they would
> horizontally fit into the HBox given a guessed height, for each
> guessed height until the minimum and natural heights are obtained.
>
> I also found that in some UIs my algorythm works perfectly,
> but as soon as you have to query a GtkLabel for its desired
> width for a given height - things break; because GtkLabel
> does not implement anything like that.

I don't think we ever want to do this kind of iterative multi-pass
layout. It could easily get prohibitively expensive.

> The really confusing and important detail to note here is that
> Clutter does none of the above, clutter does not return any
> contextual width-for-height information on a ClutterText, nor
> does it calculate the minimum/natural height of a horizontal box
> given an allocated width.
> 
> In the case of ClutterText, the width-for-height is basically
> a default minimum and natural width based on the current text.
> 
> In the case of the ClutterBoxLayout; it returns the MAX's of the
> default minimum and natural heights of all of its children.
> 
> It would be really great if someone could explain to me what
> are the tradeoffs of not implementing width-for-height in GtkLabel,
> and how it is in general that Clutter gets away with not implementing
> these.

The basic way that people get away with it is that width-for-height is
enough to do almost everythign you want, and height-for-width is just a
bit of gravy on top to make things look complete.

(This view is somewhat biased toward horizontal writing - but even for
traditional vertical-text languages like Chinese and Japanese, computer
interfaces are written horizontally.)

- Owen