Edit/Preferences/Interface/Fonts dialog:
Editor font is the only one that is honored. Even though smaller fonts are selected for symbol List and Message Window, they still display 18pt fonts, instead of 14pt. Editor font is only one that works as expected.
Fedora 28 Geany 1.34.1
WFM, always post the GTK version Geany is using (top few lines of tools->debug messages)
GTK 3.22.30, GLib 2.56.4
Hum, that's odd, WFM with GTK 3.22.11 on Debian stable. I'll try to check with 3.24 on Unstable tomorrow.
Verified that the fonts are correct in geany.conf and that changing the VTE font works.. So, edit and VTE fonts work, but not status/scribble nor symbols side panel.
Well, side panel, and status scribble are straight GTK widgets, maybe that specific version of GTK is broken with those fonts.
monospace and sans are aliases for some actual font, so what is the actual font being used?
@tempest766 Could you try also changing GTK theme? Might this be [the new Adwaita](https://blog.gtk.org/2019/01/14/theme-changes-in-gtk-3/) one? In any case, maybe a theme that would define a font very specifically for notebook tabs or so might go in the way.
@b4n even if a theme defines a default font for a text item, surely even the Gnomists are not arrogant enough to make it prevent the application changing its own font? Or are they .... hmmmm
Tested with 3.24.4 under Debian Unstable and it works fine as well.
@elextr yeah well, I guess it depends on how we do it, and which API GTK broke…
I run multiple displays with differing DPIs so I had to find a common denominator that would pass on both monitors. I have a ~/.config/gtk-3.0/gtk.css in a config directory that looks like:
`* { font-size: 16px; font-family: DejaVu-Sans; } `
but in this case the precedence is wrong. I'd expect that fonts selected in an application should override the default
OK so that's the reason, the way we apply the font must be incompatible with this. I'll check if there's something easy we can do for this not to be a problem (probably having something of the same style on our side would do, but it might be tiresome to build dynamically).
I have read the documentation of ```gtk_widget_modify_font()``` which is used in ```ui_widget_modify_font_from_string()```. The function is deprecated and the gtk documentation suggest to use ```gtk_widget_override_font()```. But that also has a deprecation remark:
gtk_widget_override_font has been deprecated since version 3.16 and should not be used in newly-written code.
This function is not useful in the context of CSS-based rendering. If you wish to change the font a widget uses to render its text you should use a custom CSS style, through an application-specific GtkStyleProvider and a CSS style class.
So I assume as soon as there is a CSS file we would need to apply a CSS style generated from the preferences settings to let the changes have any effect in this case (not tested - unconfirmed).
@LarsGit223 deprecation shouldn't mean it doesn't work, unless GTK have forgotten their promise to not break stuff until the NEXT release.
@elextr: I agree, but the sentence _"This function is not useful in the context of CSS-based rendering."_ sounds critical to me. If I find the time I will do some tests with applying a CSS style instaed of calling ```gtk_widget_modify_font()```.
@LarsGit223 The thing is that *~/.config/gtk-3.0/gtk.css* has the highest priority possible -- user priority. It's actually pretty much the right thing to do to let this win. In our specific case where it's a user setting, it could be arguable that we should give it user priority, and then it *might* work, although I'm not confident our dynamic style would overwrite anything in *~/.config/gtk-3.0/gtk.css*, unless we give it higher priority, which we probably shouldn't as it wouldn't be semantic.
All in all, I'm not even sure the behavior described in this report is wrong. After all, the user selected a specific font in a place meant to override *everything*, so why would we fight it? If the user really wants something else, it's totally possible to have the right piece of CSS in *~/.config/gtk-3.0/gtk.css* to do so, likely something like this: ```CSS #GeanyMainWindow paned>paned:first-child>notebook:first-child scrolledwindow:first-child>treeview { font: sans 12; } #GeanyMainWindow paned>notebook:last-child scrolledwindow>treeview { font: monospace 14; } ``` We could possibly make this easier by giving a CSS ID to the symbols pane's treeview if really needed, but again the only case it matters is when this gets overridden manually.
In the end, yes, providing a custom `GtkCssProvider` might work, but the priority might have to be > to `GTK_STYLE_PRIORITY_USER`, which doesn't necessarily seem like a good idea. And I'm not sure it's worth the trouble going through all this just for a corner case that already has a workaround.
@b4n I suppose that if the _user_ has the css file then yeah, its reasonable to assume they intended it and know how to put Geany specific overrides in that.
But its confusing if the GUI selection works if there is no user GTK override and not in other cases.
Perhaps the GUI selection should be removed from Geany, after all we shouldn't actually make it easy for users to override the all powerful Gnome theme using a GUI, but should tell them to go create an arcane CSS like text file in their `~/.config`.
unless we give it higher priority, which we probably shouldn't as it wouldn't be semantic.
Depends how you look at it, it's not like it's just Geany trying to force application default styles on a user, rather it's providing the _USER_ a GUI to _OVERRIDE_ the theme font, so priority higher than 800 might make some sense.
github-comments@lists.geany.org