Re: Minimum height for minimum width

[Owen Taylor <otaylor redhat com>]

On Mon, 2010-10-11 at 14:45 -0400, Havoc Pennington wrote:
> Agreed, GtkLabel needs to report min size = true min sane size and
> natural size = either full width, or "a good width"
> The full width is more correct imo, maybe we should figure out why
> that doesn't work well.

For an ellipsized label, the natural width is clearly the full width.
In this case there's an obvious interpretation of natural size because
there's a minimum size where we display all the information and above
that we're just adding padding.

But for a wrapped label, there are many different possibilities for
displaying all the information. I'm not sure that there's anything
more natural about the case where we put each paragraph on a single
unwrapped line.

Of course, if we take the position that there is never any reason to
allocate an actor more than it's natural size - if the natural size is
"all the size that is useful" - then using a narrower natural width
could be problematical, especially if things like centering are added by
the parent actor or GTK+, and not the actor itself.

> A related patch attached, if you fix this you'll quickly want it.

Yeah, came up when I was fixing gnome-terminal behavior
(see e.g., https://bugzilla.gnome.org/show_bug.cgi?id=631903)

> Also, you said if doing minimum-height-for-natural-width the window
> doesn't wrap the label and can't be made narrower. I don't understand
> that... I would expect the min size of the window is the min height
> for natural width as you propose, and the min width as returned by
> get_preferred_width(). So the min width ought to be the true min
> width?

If you use those values, then you are telling the window manager that
the window can be sized to a size that's too small for its contents.
Since GTK+ 3 basically can't handle underallocation all, this isn't
a good idea. 

(The behavior with underallocation is that widgets are
allocated with their minimum size centered at their allocated location.
Since there is no clipping this means you get a mess of overlapping
widgets.)

Setting the hints dynamically based on the current width can work, if
we're willing to say "screw wireframe resizing" (wireframe resizing
doesn't completely *not* work, you just have to release and retry
a few times to get to certain sizes.)

> Hmm. The "a good width to wrap to" thing seems like pretty much crack
> to me. If people want their window to have some sort of pleasing
> aspect ratio they should just pack the label to limit its width, or
> set default size on the window, or whatever. Or maybe GtkWindow should
> constrain the default size to "nice aspect ratio" somehow, solving
> globally for the window instead of per-label.

I certainly always saw the "good width to wrap to" thing as a workaround
for GTK+ 1/2 geometry management. But picking a good aspect ratio from
the toplevel will require a binary search. That might be fine if the
binary search is done only once when picking a default size for the
toplevel when first mapping it.

- Owen