Created attachment 100663 [details] 168 DPI screenshot with RV45 and RV48 Firefoxes loaded over/under in Plasma After https://bugzilla.mozilla.org/show_bug.cgi?id=1269274 was closed WONTFIX, I asked about this several places: https://mail.gnome.org/archives/gtk-devel-list/2016-July/msg00028.html https://lists.fedoraproject.org/archives/list/kde@lists.fedoraproject.org/thread/ZPIFOVGR6572ZR7L4TXMUXRYHQESBOPW/ http://trinity-devel.pearsoncomputing.net/?0::15168 None generated any response. According to the mozilla bug, https://git.gnome.org/browse/gtk+/commit/?id=bdf0820c501437a2150d8ff0d5340246e713f73f caused the regression. Upstream bug that could have fixed this was WONTFIX'd last October: https://bugzilla.gnome.org/show_bug.cgi?id=757142 If there happens to be an XFT.dpi setting equal to the actual Xorg display density, then UI font sizes are OK. What seems to be needed is a way for Xorg density to be automatically converted into an Xft.dpi value for the exclusive benefit of these GTK3-built apps.
I'm not sure what can we do about it from kde-gtk-config really... :/
Same issue with a 117 DPI monitor. Firefox seems very out of place.
I don't think there's anything we can do here. Seems like if the GTK folks refuse to fix the issue in GTK itself, we're kind of stuck. :( All we can do is boycott GTK apps and move to Wayland. :p
As Xft.dpi is how KDE already forces DPI, it seems logical anyone with appropriate skillset who wanted a fix should be able to create a method to read Xorg's actual DPI, extract the value, and inject that value for Xft.dpi into the xrdb environment. Thus resolving this upstream serves only to dissuade anyone from trying to create a fix.
Yes, a fix is definitely possible. But it would be a fix for GTK itself, or a workaround in xrdb or some other piece of software that makes everything play nice. This is the KDE bug tracker; we can only track issues in KDE software here. Working around GTK's frustrating bugs in the manner you suggest is distro work (and why distros exist), not something we can do.
Of course the ideal fix would be for GTK to undo the damage it caused - that goes without saying. Is KDE forcing DPI using Xft.dpi not a workaround for some other upstream problem? Saying it's not a KDE problem is no help to those suffering, because it's KDE users who do the suffering here, not Gnome users. Upstream's only incentive to fix is minimal, to have its apps play nice in other environments. So users need a workaround from somewhere, and since KDE users are one of the suffering groups, and KDE is already aware of how to alter Xft.dpi, it seems sensible for a workaround to be provided by KDE alone rather than each individual distro providing KDE.
It sounds like you have substantial technical knowledge of the subsystems in play here. Would you like to have a go at producing a patch?
(In reply to Nate Graham from comment #7) > It sounds like you have substantial technical knowledge of the subsystems in > play here. Would you like to have a go at producing a patch? If I thought I actually had the required knowledge I might, but I'm not a programmer. The way Xorg works is to me a barely navigable maze that seems to have nearly as many variations as there are Linux distros, a miracle that it works as well as it does. The only patches I've ever submitted as bug fixes anywhere have been to CSS in Mozilla. At this point I'm still hopeful that other distros will follow openSUSE's lead (reverting upstream commit[1]), and the ideal fix will ultimately come from upstream reversion. [1] https://bugzilla.opensuse.org/show_bug.cgi?id=1022830 GTK3 apps not honoring system-wide DPI settings nor KDE mouse cursor