GNOME Bugzilla – Bug 125250
Ellipsization for GtkNotebook tab labels
Last modified: 2018-02-10 04:40:14 UTC
I noticed this while using Gaim. I decided to have all my conversations to be added to the same window. Every time a conversation is started, a tabbed window is added. And i can navigate with the < and > buttons at the end of that tablist. However, if a tab has such a long name, that it is longer than the containing window, the < and > buttons aren't visible anymore. Placing those < and > buttons before the tabnames, would be more usable.
GTK 2.4 allows this via style properties that control the number and placement of the arrows.
Moving the arrows isn't the right solution. Better to ellipsize the huge label and make things fit. See long discussion in bug 115931. I'm going to retitle and leave this open because bug 115931 is a sprawling mess of a bug.
Sorry, those references were meant to be bug 110540.
I'd recommend adding a GtkEllipsizeType enum and an "ellipsize-mode" enum property to GtkLabel (and GtkCellRendererText/Progress, IMO), as this behavior is useful outside of GtkNotebook. GtkEllipsizeType { GTK_ELLIPSIZE_NONE, GTK_ELLIPSIZE_START, GTK_ELLIPSIZE_MIDDLE, GTK_ELLIPSIZE_END, GTK_ELLIPSIZE_CUSTOM /* calls a user-supplied function, fallback to NONE */ } Doing that nicely (the comments in EEL indicate that EelEllipsizingLabel doesn't) sounds like the tricky part.
Created attachment 29596 [details] [review] Patch to implement an "ellipsize" property on GtkLabel, using the PangoLayout "ellipsize" property.
Is it really necessary to add an extra enum? PangoEllipsizeMode already exists, and GtkLabel already exposes Pango API in gtk_label_set_attributes for example.
The patch above uses PangoEllipsizeMode directly, no extra enums. I was simply commenting on what a possible ellipsization enum would entail.
The label property doesn't resolve the notebook issue at all, since GTK+ doesn't currently have any code to reduce the allocation of notebook tabs on overflow. Hmm, what did you make the size request reported for the ellipsized GtkLabel be?
It's currently approximate_char_width() * 3.
That does in fact not work very well. If I turn on ellipsization on the labels in the testgtk notebook tabs, the tabs all shrink to "..." even though there is enough space ... We probably need to extend the size allocation algorithm to discriminate between "requested size" and "minimal size"
I think the request-width-chars property should make this work much better.
*** Bug 153792 has been marked as a duplicate of this bug. ***
I just used Bugzilla's search function and read this bug - http://bugzilla.gnome.org/show_bug.cgi?id=153792 - which is marked as a duplicate of this bug. I think as well that it is extremely annoying behavior in Epiphany that when you have more that 7 tabs open that you have to scroll with < and > to see the other tabs. This way tab browsing is badly usable, scrolling is annoying, I can't see if I opened a new tab if I have a lot of tabs open... so please let GTK shrink tabs and disable the scrolling through tabs. In my opinion this is a very serious issue, please fix this developers.
What do you think of applying a solution similar to the one I'm proposing for Evolution's express mode in GtkNotebook itself? Here's the bug: https://bugzilla.gnome.org/show_bug.cgi?id=653113 We would make sure the requested size for the tab label is not bigger than a proportion of the allocation of the notebook, set the request appropriately, and set the label to ellipsisize.
We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue for it.