Pluma using incorrect font for context menu in 19.04

Support & Help Requests
#1

Like it says. I think that's one of the "Ubuntu" fonts but that's just a guess: what I do know is, it's not the font that it's been told to use and that everything else on the system (caja etc) correctly does for all of their context / popup menus.

pluma-popup_wrong-font
pluma-popup_wrong-font.png1920×1200 70.6 KB

The bug isn't present in 16.04, so it's probably from 18.04 and the move to GTK3, but I can't bisect it further than that. The reason I'm posting here rather than just going straight to launchpad is in case someone has a workaround for it that can be used in the interim. (Bed now, launchpad tomorrow).

Thanks.

#2

This was definitely fixed for 19.10.

Try the latest themes, either by:

Then "reload" the theme to see the new changes - either by logging out or switching between them in :appearance: Appearance.

2 Likes
#3

Thanks. I'm fairly sure that's not monospaced text though: it looks like a proportional font to me. (My eyesight's not great though, so I could be wrong).

The gtk-widgets css file for the theme also already contains this:

/* work around a bug with GtkSourceView using a monospaced font for these (pluma etc) /
/ see Ubuntu MATE 19.04 Beta is out! */
.context-menu {
font-weight: normal;
font-family: regular;
}

which I'm guessing is the bugfix you're talking about.

So the problem seems to be that pluma / GTK is translating "font-family: regular" as "font-family: some random font rather than the menu font". neh?

#4

I just doubled check on a clean 19.04 - the context menu is no longer fixed width (monospace)

Before & After

Before After

It is a theme bug. GTK themes follow the rules of CSS - so since the theme didn't properly specify which font weight/variant to use, GTK inherited the parent style (the font used for GtkSourceView / text area).

Take this serif font, for example:

Screenshot_20190914_140837
Screenshot_20190914_140837.png835×367 24.8 KB

Before with a serif font

#5

Thanks, that's interesting to know.

I don't see how I can turn that into a solution for the core problem though, which remains that pluma is not using the menu font for the menu.
To be clear: this is not about the menu being monospace, it's about it using the wrong font entirely, proportional or not. There is a font specified for menus. pluma (via GtkSourceView) is not using it for that context menu, and it should be.

Since the menu font is system-wide and not part of the pluma theme, no amount of changing the css will fix it unless there's a solution along the lines of "font-family: use-the-menu-font" - what I'm looking for (though not expecting to actually find) is what that syntax is.

Hopefully that's clearer?

#6

No, it definitely wasn't. The monospace problem was, but that was never my concern - pluma (and IIRC caja and probably every other context menu) still uses an arbitrary font arrived at through a chain of bugs and random fallbacks, rather than the user's chosen menu font.

I'm not expecting that it'll actually be properly fixable at all, since that would require GNOME to upstream a patch, but I intend to at least trace it and see if it can be persuaded to end up at the right font without every single app needing to fix it separately.

#7

With openSUSE Leap, Pluma running in XFCE does not obey the configured desktop font. You can see here a mishmash of programs running, and the only one that doesn't adhere is Pluma for some reason. Even Engrampa does have the correct fonts.

Screenshot at 2020-07-05 15-42-11
Screenshot at 2020-07-05 15-42-111919×972 113 KB