Re: Minimum height for minimum width

[Havoc Pennington <hp pobox com>]

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.

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.

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

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

Havoc