GNOME Bugzilla – Bug 787260
Too large window title padding on the right
Last modified: 2020-02-19 10:25:14 UTC
Created attachment 359085 [details] Screenshot See screenshot
What is the bug (in your opinion)? Do you mean the padding between close button and other titlebar elements? (In that case, gnome-shell isn't involved at all, as the window uses client-side decorations - that is, the entire titlebar is handled by the app/toolkit)
Created attachment 359086 [details] Screenshot v2 Sorry, I was unclear. I've marked it on the screenshot now. Another example is here: https://didrocks.fr/images/artful-shell-transition/overview.png See "Documents " on that screenshot. The longer the title is, the larger is the space there.
OMG, I've only now noticed that I typed "titlebar" instead of "title".
(In reply to Alexander Mikhaylenko from comment #3) > OMG, I've only now noticed that I typed "titlebar" instead of "title". Yup, that's what threw me off :-)
Created attachment 359087 [details] Screenshot of long window title text Seems the padding (of the on-hover window title label displayed on the lower part of the window preview) gets bigger for longer texts. Is that expected? Attaching two screenshots for comparison
Created attachment 359088 [details] Screenshot of short window title text
Created attachment 359091 [details] Another screenshot of a long window title (In reply to Jonas Ådahl from comment #5) > Created attachment 359087 [details] > Screenshot of long window title text > > Seems the padding (of the on-hover window title label displayed on the lower > part of the window preview) gets bigger for longer texts. Is that expected? No, it's not expected. In fact, I'm not seeing the issue at all (see screenshot), nor is there anything suspicious at a quick glance - there's nothing manual about the padding, it's simply CSS applied to a label ...
Hmm, I can't reproduce this anymore on GNOME Shell 3.26.0, at least on X11.
Can confirm in Wayland, but cannot reproduce on X. Same padding to the right of title just as in the screenshots already attached here.
*** Bug 788660 has been marked as a duplicate of this bug. ***
(In reply to Florian Müllner from comment #7) > No, it's not expected. In fact, I'm not seeing the issue at all That was because I was on X at that moment - as others have noted, this is a wayland issue. But it's still a mystery to me what's going on: - the width request of the label's ClutterText is correct - the horizontal padding stored in the label's theme node is correct - the label's width request boils down to "clutter_text's width + padding", but for some reason is too big on wayland
*** Bug 788849 has been marked as a duplicate of this bug. ***
It may be worth noting this wasn't happening in 3.24.
When investigating this issue I noticed that using Main.layoutManager.addChrome() to add the label instead of adding it to parentActor seems to result in the correct size. This is also what the dash tooltips use. I'm not sure why this works and I doubt it would be the correct approach though. Maybe the WindowCloneLayout LayoutManager does something that affects the label size that the other LayoutManager doesn't do.
Created attachment 370910 [details] Empty space on the right with Cantarell at 10 pt
Created attachment 370911 [details] Ellipsized text with Cantarell at 12 pt on X11
Created attachment 370912 [details] Ellipsized text with Roboto at the default 11 pt on X11
A variant of this issue can be observed on X too, if the shell font is set to anything other than Cantarell at 11 pt. It looks like the window caption width is always calculated for Cantarell at 11 pt. If the currently selected font requires more space, the text is ellipsized at the end or if it requires less space, empty space is left over on the right. I have attached screenshots from a fresh install of Fedora 27 to demonstrate the issue.
Still valid for Gnome 3.30 on Arch Linux.
I can confirm this issue on my Fedora 27 Gnome 3.28.3! Check this GitHub issue out for more details: https://github.com/horst3180/arc-theme/issues/888 Hope to fix soon!
This bug persists with Gnome 3.32 on Arch Linux.
Still happening with 3.34 (Fedora).
Fixed in https://gitlab.gnome.org/GNOME/gnome-shell/commit/cf52047