Re: Minimum height for minimum width

[Tristan Van Berkom <tristanvb openismus com>]

On Tue, 2010-10-12 at 09:45 -0400, Havoc Pennington wrote:
> Hi,
> 
> On Tue, Oct 12, 2010 at 2:44 AM, Tristan Van Berkom
> <tristanvb openismus com> wrote:
> > 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 point here was mostly about the natural width. I don't have a lot
> of opinion about what min sane size is (though in general I think it
> should be "smallest size that can work at all")
> 
> > 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.
> 
> IMO this should never be necessary unless something is broken. The
> toplevel should pick a default size that's no larger than maximized
> (work area) by default, if it can do so while staying above its min
> size. (This may be an important addition to that "GtkWindow default
> size = natural size" patch.) Widgets should not have to do a bunch of
> custom f*ing around logic. They should report min useful size and max
> useful size, done and done. If that doesn't work, the toolkit is
> broken. Label trying to second-guess stuff to keep the toplevel aspect
> ratio correct is just broken.

I'm not sure what exactly you are talking about here, the only guess
a label currently makes is for a reasonable "width-chars", i.e. limiting
a wrapping label to a reasonably large minimum width. This is to avoid
unreasonably large heights in proportion to the width.

I don't think that its right to allow the minimum width to be
as small as a single word, that either results in:

  a.) requiring the height-for-minimum width at all times in the
      window (current behaviour)

  b.) letting the user shrink the window's width too small and grow the
      window's height too much (if we were to constrain window size
      dynamically)

Sure, the programmer is allowed to set a small minimum width
via the "width-chars", but lets not encourage him by making
it the default behaviour of the label.

If you disagree with that, then what would you have the label do
in place ?

Please explain where we are second-guessing stuff and how exactly
the toolkit is broken, then we can move on to fix it.

So far the two things I would change (or add as enhancements) are:
  a.) Add a feature to let the GtkWindow choose a default size 
      according to the natural size clamped into the screen size
  b.) Try making the window's height constraint contextual to
      the window's allocated width.

I wouldn't say the toolkit is broken just because we haven't yet
added those features.

> Now, we've just established that due to the WM interaction we may have
> to be broken at least on X ... ;-) but hopefully the consequences of
> that limitation can be minimized. In theory we could pretty quickly
> get a new WM protocol in metacity/gnome-shell to fix it for real, too
> - if we know what the protocol is, which I don't.
> 
> The only time I think you should have to do max-width-chars is when
> you don't want the window to ever default to full screen width
> (presumably you decide this is just ugly, for example). You shouldn't
> have to set this to unbreak stuff - for example, you shouldn't have to
> set it just to keep the window from going off the screen.

Good point, if we add a feature to GtkWindow to set a default size
automatically according to its natural request, then this would become
apparent.

One place for instance we would definitely want to set "max-width-chars"
is in GtkDialog texts (generally we dont want single line-high dialogs
that span the whole screen width, of course).

Other places we would want to use "max-width-chars" would be in cell
renderers, depending on the view's design I think alot of cases would
like to restrict the natural size of a column in proportion to it's
surrounding columns - if only to achieve a desired look and proportion.

> 
> btw shouldn't max-width-chars be called natural-width-chars?

It's called "max-width-chars" because the property already existed,
we just used that same property in context of the new geometry
management system (just to not add more api bloat).

> >> 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.
> 
> I think a good first cut would be "natural width constrained to work
> area size" - the WM may already do that constraint anyhow, hopefully.
> Some windows might be sort of oddly wide compared to their height but
> they won't go offscreen. Making things a pretty aspect ratio could be
> done via binary search, but maybe is better done by just letting apps
> set max-width-chars or otherwise messing with their layout. Doing it
> by magic picking of a "good wrap width" by default ... eh. Such a
> weird hack.
> 
> > 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).
> 
> I don't think anyone was suggesting this

It was my original impression that Owen was suggesting a window should
be constrained to the minimum-height-for-natural-width, which caused
me to be initially alarmed.

Cheers,
      -Tristan