Re: Minimum height for minimum width

[Owen Taylor <otaylor redhat com>]

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.)

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.)

> 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?

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!)

> > > 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