GNOME Bugzilla – Bug 406528
Ellipsize doesn't work properly with a multi-line label
Last modified: 2010-05-22 04:27:11 UTC
Please describe the problem: If you have a gtk.Label() with multiple lines (i.e. "text\ntext") and set the ellipsize mode as pango.ELLIPSIZE_END, the end result is clearly incorrect from what is expected. Here are two screenshots to demonstrate: http://people.os-zen.net/stonecrest/pango_bad.png http://people.os-zen.net/stonecrest/pango_good.png As you can see, there is more than enough space for both lines to appear, but both end up ellipsized. I would expect each line to only be ellipsized if the line cannot fit in the label width. Steps to reproduce: 1. 2. 3. Actual results: Expected results: Does this happen every time? Other information:
Which version of gtk+ exactly is this?
2.10.9 currently. It has definitely happened with previous versions as well, although I can't say exactly which. Actually, I should note that I haven't tested this simply with a gtk.Label(). I've only tested it with an expander, as shown in the screenshots. I don't know if that makes a difference.
It probably works with GtkLabel. Can you attach a test case of the broken code?
Here you go, it's in python: http://sonata.berlios.de/bug.py Just click on the expander to switch between the no ellipsizing and ellipsizing situation. The width of the expander doesn't change.
Created attachment 89138 [details] Quick C version of the testcase As requested by Behdad. Hope that the translation is right...
Thanks Kris. No idea what's happening here, or what the desired behavior is.
Hi!! I've been reviewing the bug a bit and I think I've found the problem. It's a combination between the size_request politic of the ellipsized gtklabel and the size_allocation of the gtkexpander. An ellipsized gtklabel always returns as its size request the size needed to draw the three dots. The gtkexpander, in its size_allocate, asks to the label its requisition, calculates the space the label should have (to fill the expander), and makes a MIN() between both values to get the final label allocation. No matter how big the expander is, the allocation for the label will always be the three-dot-size. And as the label, when ellipsized, shows as much caracters as possible until if fills the allocation, it will only be able to show the three dots. The problem is that the expander trusts the label's requisition, but it's invalid when ellipsized. The expander should give to the label the allocation needed to be filled, and then the label will adjust its size to fill the expander. A possible solution to the bug is removing the MIN() operation of the expander's size allocate, so the size given to the label is always the size needed to fill the expander. I can't think of any possible side effect of removing that operation, but maybe there are some and I didn't realize. I'll send a patch so you can check what I mean. Greetings!! ;)
Created attachment 99854 [details] [review] Patch that ignores the gtklabel's requisition to assign its allocation Hi again! As I said, this patch solves the bug ignoring the gtklabel's requisition in the expander's size_allocate. What do you think? Greetings!!
The extended-layout branch should solve this. Your patch may have implications in right-to-left layouts.
Yeah, I know what you mean :( It's a bit complicated to right align the label when you don't know the size the label will finally have. Well, as this problem will be fixed with the extended-layout, as you said, I'll move to work on another bug. Greetings!
Update, native-layout[-incubator] branch does address this. Noting here that GtkExpander should ideally be updated to: - Consider the natural width of it's label (that alone will fix this ellipsize bug particularly). - Share allocated space between the expander header and the child widget in the way boxes share space among children. (this will help optimize space used by expanders in general). - Report the collective minimum and width and height of the expander with the child and the label included (this will allow expanders along with their content to request contextual heights for allocated widths and vice versa). Note that GtkBin widgets have an automatic implementation of height-for-width/width-for-height apis that assumes the padding of the bin widget is constant, that assumption will surely not hold for the expander widget. o When the expander is closed, only the label needs to handle the requests and the padding calculated o When the expander is open; it should do a collective height-for-width/width-for-height operation; the algorithm can be the same as in GtkBox.
This has been fixed as part of the extended layout work that Tristan has done for 3.0.