Re: Please fill out the GtkLabel questionnaire

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

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

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