Re: Minimum height for minimum width



Sigh, alright can of worms open.

Not sure exactly where to start here but lets keep in mind that
of course, any window must fit all of its screen content at all
times, that's not to say that it requires the 
minimum-height-for-minimum-width at all times, but only when it's
allocated it's minimum width (as Owen pointed out before, it's quite
possible to bump the window's height constraint in a more dynamic way;
while growing the window's height as needed when the user shrinks it's
width, I have not tested this but I think its a behaviour worth
considering, ofcourse we would not want to *shrink* the window's
height automatically when the user grows the width, that would look
just awkward IMO).

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.

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

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

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

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

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.

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

Cheers,
     -Tristan

> 
> - Owen
> 
> 
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]