Re: Please fill out the GtkLabel questionnaire

[Tristan Van Berkom <tristanvb openismus com>]

On Sun, 2011-04-10 at 00:42 +0900, Tristan Van Berkom wrote:
> On Sun, 2011-04-10 at 02:58 +0200, Benjamin Otte wrote:
> > On Sat, Apr 9, 2011 at 2:14 PM, Tristan Van Berkom
> > <tristanvb openismus com> wrote:
> > > What I should have done, as Owen pointed out back in december was to
> > > leave the label requests very straight-forward and require the program
> > > author to set an explicit minimum size of the toplevel GtkWindow,
> > > essentially the difference would only be that instead of having to
> > > potentially configure a lot of label sizes inside the interface, you
> > > just configure the desired size of the toplevel and you get a reasonable
> > > allocation (Havoc also suggested we do some one-shot binary search to
> > > find a good aspect ratio for the initial size of the toplevel window).
> > >
> > So what you are saying is to essentially get rid of the
> > guess_wrap_width argument to gtk_label_ensure_layout(), right?
> 
> Unfortunately we did not make the change before releasing 3.0 so now I
> guess we're stuck with the wrap width guessing (any interfaces
> with wrapping text would suddenly be effected and have a tall and 
> thin size)... possibly we could fix it by adding api to gtklabel
> (however the apis that would be needed to opt-out of the wrap-width
> guesswork don't sound very attractive).
> 
> > 
> > > A caveat here is that currently there is no straight-forward way for
> > > obtaining things like "the size of the largest word in the text" or
> > > "the size of the widest character".
> > >
> > According to Behdad:
> > pango_layout_set_wrap_mode (layout, mode);
> > pango_layout_set_width (layout, 0);
> > pango_layout_get_extents (layout, &extents);
> > will give you exactly that. It will cause as much wrapping as possible
> > and then of course the width of the resulting text will be the size of
> > the widest word/character.
> 
> That's very fortunate :) we can use that to avoid
> clipping when using width-chars properties (we have
> the same problem with cell renderers too).
> 
> > 
> > > Labels currently don't wrap and ellipsize both, it would be nice if
> > > they did however (and it's certainly possible, I would imagine the
> > > whole text would wrap as much as possible and the text that doesnt
> > > fit would be ellipsized only on the last line).
> > >
> > Oh? Is this a limitation in Pango or is that just missing inside GtkLabel?
> 
> Looks like we could use pango_layout_set_height ().
> 
> > > As far as "max-width-chars" and "width-chars" effects go, I dont have
> > > any strong opinion so far as it's useful, the subtleties are:
> > >
> > >  - Do we blatently always request "width-chars" as minimum if set ?
> > >  - Do we request MIN (text_width, width-chars) ?
> > >    (I think this is more useful and I think it's how it currently
> > >     works)
> > >
> > > Same for max:
> > >  - Do we blindly request "max-width-chars" as the natural width ?
> > >  - Do we request MIN (text_width, max-width-chars) as natural ?
> > >    (Again I think it's currently the latter and I personally think
> > >    that is more useful).
> > >
> > Paolo and I discussed that, and what we discussed was setting the
> > minimum/natural size in characters.
> > There seem to be 4 values that you could want to set:
> > - minimum value to request for minimum width
> > - maximum value to request for minimum width
> > - minimum value to request for natural width
> > - maximum value to request for natural width
> > And we have two properties for them:
> > - width-chars
> > - max-width-chars
> > 
> > Now I would argue that 2 of the values are kind of useless: the
> > maximum minimum width and the minimum natural size. If you'd agree
> > with that premise, you could use width-chars as the minimum minimum
> > width and max-width-chars as the maximum natural size. (Which is what
> > I did in my reply.)
> 
> I think I agree... max-width-chars should be the limit of natural
> text width.
> 
> the other is harder... width-chars is currently useful to make 
> sure wrapping labels request enough width (and the UI ends up 
> really tall, hence we have the wrap-width guessing fallback).... 

Err, "and the UI ends up..." should read "Otherwise the UI ends up..."

> Questions about width-chars ...
> 
> should a wrapping/ellipsizing label have an api to set the 
> absolute minimum size in characters ? 
> 
> I think probably yes
> 
> should such a label have an api for limiting the minimum request ?
> (i.e. 'MIN (text_width, width-chars)')
> 
> I think definitely yes 
> 
> should a label have a way to request at least 'n-chars' in width ?
> (i.e. 'MAX (width-chars, MIN (text_width, max-width-chars))')
> 
> Yes I think that's useful too (for cases where you want to show 
> some labels in a status bar about download speed and progress, 
> and you want to use something like width-chars to ensure some 
> padding for your labels so they don't lose their alignments
> unnecessarily every time you update them).
> 
> This bug: https://bugzilla.gnome.org/show_bug.cgi?id=644007
> describes a similar case (and iirc gtklabel.c does some weird 
> manual checking of GtkWidget's 'aux_info', that code should
> probably go away).
> 
> Maybe enum properties for "minimum/natural request in characters"
> would be clearer and also more powerful at the same time.
> 
> > The only question that would remain is how you let these properties
> > interact with the width required by the label's text. I assumed that
> > the minimum width of the text is bigger than any of those properties,
> > that size will be used instead, but the natural width of the text is
> > ignored if the max-width-chars property is set.
> 
> > Benjamin
> 
> 
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list