Re: Minimum height for minimum width

[Tristan Van Berkom <tristanvb openismus com>]

On Tue, 2010-10-12 at 12:09 -0400, Owen Taylor wrote:
> On Tue, 2010-10-12 at 15:44 +0900, Tristan Van Berkom wrote:
> 
> [...]
> 
> > Also... lets try to break this down into two separate issues at hand.
> > 
> > First issue being that the window requires enough height to fit the
> > windows minimum width at all times... this is because we dont to any
> > dynamic updating of window constraints based on window allocations.
> 
> *Even if you don't do any dynamic updating* the minimum-for-minimum
> approach isn't inherently right, it's a decision that you are making. A
> height-for-width window content doesn't have a single minimum size, it
> has a range of minimum sizes:
> 
>  +---+  +-----+ +----------+ +------------------+
>  |   |  |     | |          | +------------------+
>  |   |  |     | +----------+
>  |   |  |     | 
>  |   |  +-----+
>  |   |
>  +---+ 
> 
> You are saying that we should always pick the left-most version - the
> tallest version, and make that the minimum size and the default size.
> (Without dynamic updating, minimum and default size should be the same
> for a window without any expandable areas; e.g. a dialog with buttons
> and labels, since a bigger default would just add useless excess space.)

I've been saying that for a height-for-width layout the leftmost should
be chosen for the minimum size yes. The default size is usually left up
to the  programmer to decide (the right-most would a be more ideal
minimum size for width-for-height layouts).

Why ? because that offers the most flexibility for height-for-width
widgets in the UI, i.e. labels are allowed to reach their minimum
size.

However that's not to be stubborn and say that I'm right %100 of 
the time, its only the logical conclusion I came to when facing
the restriction of having to chose a final minimum size (and
not update the constrained height dynamically).

> 
> The corollary to this is that if I'm designing a window I have to make
> the minimum width on the window the "right" width - the width where it
> has a pleasing aspect ratio and looks good.
> 
> Maybe this is a reasonable conclusion, but it's not some inherently
> logical conclusion.
> 
> > Second thing is that Owen disagrees that the minimum wrap width of
> > a label should be limited to something greater than the size of the
> > largest word.
> > 
> > My initial thoughts on these issues is that:
> >   a.) dynamic constraints on GtkWindow is something worth experimenting
> >   b.) The minimum size of a label is not a "hack" just because of our
> >       current minimum-for-minimum policy on window constraints, and
> >       for the most part should be left as is.
> > 
> > Comments in line...
> > 
> > On Mon, 2010-10-11 at 15:30 -0400, Owen Taylor wrote:
> > > 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.
> > 
> > I'm not sure you agree completely here, are you saying that a
> > wrapping label's minimum width should be the width of the largest word ?
> > or it should be a true sane minimum size ? My opinion is that a single
> > word wrap width is definitely not a sane minimum size at all.
> >
> > In other words I don't think its a sane idea to allow the user to shrink
> > the window's width so much that its height probably flows right off
> > screen (leaving larger paragraphs virtually unreadable in a single
> > column when hitting the minimum constraint).
> 
> You are jumping from a conclusion about windows to a conclusion about
> labels. Yes, if I have a window with a single label in it, and I've
> implemented height-for-width window constraints on it in some fashion,
> then it doesn't make sense to allow the user to accidentally reflow the
> window so it is 5000 pixels tall. We want a reasonable minimum width on
> the window.
> 
> But that doesn't mean that that "minimum reasonable width of a window"
> should be used for "minimum reasonable width of a label" - there are
> lots of other places where a label can be used.
> 
> If someone is using a layout editor, and they add a label for a name,
> and they decide that they want it to wrap onto two lines when necessary,
> they are going to be very surprised when setting the label wrappable
> suddenly makes everything expand way out horizontally. Yes, they can
> find the width-chars property and crank it down, but I don't think this
> is expected behavior. Keeping to expected behavior is important for
> making people understand what's going on... it's better to have people
> reason out:
> 
>  "Oh, if I don't set a minimum width on the window, then the user can
>   resize it way down and it gets too tall, I better set a minimum 
>   width"
> 
> Than learn:
> 
>  "Labels in GTK+ start off with a magic width that seems to be around
>   40-50 characters wide. If you want to make a wrapping label narrower
>   than that you have to set the width-chars property"
> 
> The first way may not be any easier than the second way, but it's far
> less magic and more comprehensible.
> 
> Now, obviously if we combine:
> 
>  - Label doesn't have a magic minimum width when wrapping
> 
> With:
> 
>  - Window starts off with minimum width
> 
> Then that also could produce something a little unexpected - but I think
> it would be better to have an artificial minimum size enforced by
> default on GtkWindow than on GtkLabel. (For one thing, it deals with
> things that are *like* GtkLabel.)

To clarify whether I'm understanding you correctly, you would
have the user set an explicit minimum-width on the GtkWindow
(or have GtkWindow do some kind of heuristic guessing)
and then let the content fill however it ends up filling ?

Then the window constraint would still be the minimum height for 
the minimum width, only the minimum width would be defined by the 
user instead of being derived by the collective minimum width 
of the child widgets, correct ?

These are very good points.

I'm sorry to disappoint by not having reached that conclusion
on my own in the three weeks which were allotted me to actually
land this mountain of changes in GTK+.

It may turn out to be a minor detail to change this from the 
GtkLabel and GtkWindow point of view - and as I've not tried
applying such a technique to GtkWindow instead of directly
to GtkLabel - I naturally don't know what the results would
look like.

Also, when combining width-for-height with height-for-width
recursively down the hierarchy, I have to say it worries me
at least a little to allow "single-word-minimum sizes". Really
there's no way around requesting the height-for-minimum-width
when a child is asked get_preferred_height(). However in these
cases explicitly setting "width-chars" on labels should help
produce reasonable results.

 -Tristan

> > However, currently we use "width-chars" property of label to allow
> > the user to declare an unreasonably small minimum width for a label
> > (very small minimums IMO should only be used for some static text 
> > that is known to never be a long paragraph, thus never pushing 
> > window height to an unreasonably large value when allocated its 
> > minimum width).
> 
> Again you are jumping from label to window. In general, in most real
> layouts, labels will always be allocated a reasonable amount of width
> even if they have very small minimum sizes.
> 
> > > 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.
> > 
> > I don't completely agree here either, in many cases that are important
> > to handle the text displayed in a label is some user input, data loaded
> > from a database or even some translated text that wont fit normal screen
> > constraints (same goes for the natural width of a GtkCellRendererText).
> > 
> > For this reason it is important for the programmer to consider setting
> > "max-width-chars" on a label that may have overly large text.
> > Ellipsizing labels will still consume more space when allocated any
> > further space via its "expand" or via resizing of treeview columns
> > (for cell renderers).
> 
> I think you need to think very carefully about how natural width is
> explained and documented, since it seems to be neither exactly:
> 
>  - the maximum useful width
>  - a "good width" for the widget
> 
> I get the impression from the above that the main point of natural size
> is that once a widget reaches it's natural size it will stop competing
> with other widgets for space?

Correct.

> That may be a useful concept, but if we can't coherently document and
> explain natural width, then we'll have a decade of confused programmers
> on our hands. (I'm confused right now!)

Sure, that shows that we have much documentation to improve.

> > > > 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.
> > 
> > Not sure where this portion is going, ofcourse setting the default width
> > of a window to be the natural width of the window should be fine and
> > doable, using reasonably sized labels and good judgement with
> > "max-width-chars" this is currently doable.
> 
> If the minimum height of a window is the minimum height for the minimum
> width, and the natural width of a label is the width with no wrapping,
> then no, making the default width of the window the natural width of the
> window doesn't work.
> 
> > One thing I have to add is that constraining the width of the window
> > to be the natural width of the window is surely not what we want; It
> > would mean that minimum sizes of labels are then unattainable
> > completely (in which case, why have a minimum size at all ? the minimum
> > then becomes the natural for the whole window's content).
> 
> There's no getting around it, for GtkLabel in GtkWindow, if we have a
> single minimum size without height-for-width, then we don't have useful
> reflow - we just have a single layout with a size determined by the
> programmer.
> 
> I don't think that there's anything worse in using
> 
>  natural width
>  minimum height for natural width
> 
> For that layout than:
> 
>  minimum width
>  minimum height for minimum width
> 
> these are both equally good "minimum sizes". The only real questions are
> what the other consequences are of each decision - how does that affect
> other uses of minimum width and natural width.
> 
> - Owen
>