GNOME Bugzilla – Bug 774248
Desktop-wide text scaling factor is ignored by gtk_widget_override_font() (GTK+ 3.22 regression)
Last modified: 2018-02-05 17:59:51 UTC
Since GNOME 3.22 the GtkSourceView widget (as used in gedit, gnome-builder, etc.) ignores the text scaling factor set in the "org.gnome.desktop.interface.text-scaling-factor" gsettings key. As a result, all text is scaled properly, except in the GtkSourceView widget, which is much too big (in my case). Setting the font size to something like 8pt manually is not really acceptable, because that also affects gnome-terminal (which scales fonts correctly).
*** Bug 771898 has been marked as a duplicate of this bug. ***
Moving to GTK+, because GtkSourceView didn't deal with this, and it is useful for all GtkTextView widgets, not just GtkSourceView.
Not seeing that here, with gtk3-demo, you will have to give a concrete example where you see it failing.
(In reply to Fabio Valentini from comment #0) > Since GNOME 3.22 the GtkSourceView widget (as used in gedit, gnome-builder, > etc.) ignores the text scaling factor set in the > "org.gnome.desktop.interface.text-scaling-factor" gsettings key. I supposed that that sentence was true and concluded that it's a gtk bug since GtkSourceView doesn't deal with the text-scaling-factor. But after testing myself, gtk3-demo works fine and gtksourceview's various tests work fine too. So the problem is in gedit and gnome-builder.
I am sorry about the confusion - but the gnome-builder behavior seems to have changed (to the correct one) since I originally reported this bug in the fedora bugzilla about a month ago (so I was wrong about the source of the problem, sorry about that). Now, the only applications I can find where the text doesn't scale correctly are "gedit" and "scratch" (the elementary text editor).
(In reply to Fabio Valentini from comment #5) > Now, the only applications I can find where the text doesn't scale correctly > are "gedit" and "scratch" (the elementary text editor). For me it's gedit and meld (http://meldmerge.org/)
Also seen on anjuta 3.22.0, new mail composer in evolution 3.22.2, meld 3.16.3, latexila 3.22.0 so far. System info: openSUSE Tumbleweed, GNOME 3.22.2
I'm seeing this in gedit and the evolution composer (I filed https://bugzilla.gnome.org/show_bug.cgi?id=774596 on that) on my laptop after upgrade from Fedora 24 to Fedora 25 (and switch to Wayland).
*** Bug 774596 has been marked as a duplicate of this bug. ***
I suspect that the bug comes from the use of gtk_widget_override_font(). It's a deprecated function. (But even for deprecated functions, regressions should be fixed).
(In reply to Sébastien Wilmet from comment #10) > I suspect that the bug comes from the use of gtk_widget_override_font(). > It's a deprecated function. (But even for deprecated functions, regressions > should be fixed). after reverting: css: Fix case where we didn't convert pt => px https://git.gnome.org/browse/gtk+/commit/?h=gtk-3-22&id=5ccc0e40f5eaa9c0e2121674913c398e9963f0be text size is more what I would expect with a scaling factor of 0.8
Moving to GTK+, I'll attach a small test case. The bug occurs if gtk_widget_override_font() is called.
Created attachment 340837 [details] Test case that calls gtk_widget_override_font()
Documented for F25 at https://fedoraproject.org/wiki/Common_F25_bugs#wayland-hidpi-gedit-evo .
(In reply to Adam Williamson from comment #14) > Documented for F25 at > https://fedoraproject.org/wiki/Common_F25_bugs#wayland-hidpi-gedit-evo . Please note that this is not a Wayland-specific issue. I see it here on X11.
Absolutely, this problem is independent of wayland - I am running gnome on Xorg atop NVIDIA drivers, so definitely no wayland involved ...
huh, thanks, I'll correct that. guess I didn't actually try X on my affected system.
(In reply to Adam Williamson from comment #14) > Documented for F25 at > https://fedoraproject.org/wiki/Common_F25_bugs#wayland-hidpi-gedit-evo . I bet Evolution and gedit are actually different bugs with the same symptom. WebKit requires applications compute text size manually based on the size of the monitor and pixel density. I wish I were kidding, but we just copy/paste the same 100 lines of code to do this among a bunch of different GNOME apps; each new app that uses WebKit doesn't know to do this and is broken until we figure it out, and it's easier to copy/paste than spend a day fixing WebKit and writing layout tests for it. You might want to file an Evolution bug pointing at https://bugs.webkit.org/show_bug.cgi?id=142673#c6
I guess. It *used* to work with Evo, though, and then suddenly stopped working on upgrade to F25. Just like gedit.
Remember F24->F25 means Evo has switched to WK2
Fair enough. I guess I'll re-open my 'dupe', then.
With 3.23.91, only the problems with gedit, anjuta, latexila remain. evo is fine now, so is builder (from my not-so-rigorous testing). Couldn't test meld yet.
*** Bug 784271 has been marked as a duplicate of this bug. ***
*** Bug 782526 has been marked as a duplicate of this bug. ***
Also reported at Ubuntu as https://bugs.launchpad.net/gedit/+bug/1700092
Hey Company, looks like this is a regression from one of your commits, see starting at comment #10
ping?
Created attachment 363551 [details] [review] css: Add a workaround for gtk_widget_override_font() The problem here is that the CSS machinery expects font sizes to be in pixels, but gtk_widget_override_font() provides a value in point and the CSS machinery has no ability to query the DPI and convert. This patch changes the dconversion DPI we use from a hardcoded 96 to the default screen's DPI, which should work better than before. This will of course not listen to changes in the default screen's DPI, but that shouldn't be a problem. People who want to workaround this should use gtk_widget_override_font() with a font that has an absolute size set via pango_font_description_set_absolute_size (size * PANGO_SCALE * gdk_screen_get_resolution (screen));
Does this patch work better? It's a problem resulting from a cleanup we did to unify the handling of font sizes in GTK to fix various issues and we had to judge what the best place was to hide the fallout and we chose gtk_widget_override_font(). The fix mentioned in the patch of using pango_font_description_set_absolute_size() might be a useful workaround for GtkSourceView (Assuming it works as I think it should, I did not test it right now).
The "org.gnome.desktop.interface.text-scaling-factor" gsettings key apparently doesn't work on Xfce, but maybe the patch works fine on GNOME, I haven't tested on GNOME.
Attachment 363551 [details] pushed as 6ff326a - css: Add a workaround for gtk_widget_override_font()