Mozilla apps built with GTK2 have been only too happy to have their UIs obey X configuration determined via either startup xrandr or xorg.conf*. Xft.dpi has been an unnecessary optional parameter outside of Gnome-based environments. Last year, respect for X configuration was removed from GTK. UI text sizing in Mozilla apps built with GTK3 shrunk when run in >96 DPI environments. Presumably, other apps built with GTK3 exhibit similar regressive behavior, but as a KDE and TDE user I'm not familiar with any such apps. Post-GTK-3.16, absent an explicitly configured Xft.dpi, Xft.dpi:96 is assumed. As a result, Mozilla apps run in KDE, TDE and other non-Gnome, non-96 DPI environments are not utilizing the font sizes specified for the DE's UI. Thus, UI text in GTK3 builds of Firefox, SeaMonkey and Thunderbird in the usual cases (>96) are smaller than in all GTK2 and QT apps when the DE is not Gnome-based. Attempting to have this problem addressed via mozilla.org and gnome.org bug trackers has generated wontfix responses. What could work around the problem is as stated in $SUBJECT: generating Xft.dpi from server dimensions at startup whenever it has not been specified via configfile. It's already somewhat cumbersome to automatically force DPI to accurately reflect physical display density or some arbitrary value using either xrandr or DisplaySize. Users shouldn't need to manually configure Xft.dpi as well when the server or some startup utility could generate it automatically. WONTFIXED Mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1269274 WONTFIXED Gnome bug: https://bugzilla.gnome.org/show_bug.cgi?id=757142 Git commit responsible for behavioral change post-3.16: https://git.gnome.org/browse/gtk+/commit/?id=bdf0820c501437a2150d8ff0d5340246e713f73f
I disagree. There is absolutely no reason why it should be up to Xorg to bend over backwards to work around breakage _explicitly introduced_ by external developers. Xorg already provides a multitude of tools to expose DPI information (core API about display width and resolution, XRANDR information). If the toolkit refuses to use them, that's the toolkit issue, and users should complain with the toolkit developers (or work around the toolkit breakage in whatever way they can).
(In reply to Giuseppe Bilotta from comment #1) > I disagree. With what exactly? > There is absolutely no reason why it should be up to Xorg to > bend over backwards Would it really be bending over backwards to provide a workaround for this particular GTK rudeness? > to work around breakage _explicitly introduced_ by > external developers. Not any ordinary developer, but an unavoidable rhinoceros herd. > Xorg already provides a multitude of tools to expose > DPI information (core API about display width and resolution, XRANDR > information). If the toolkit refuses to use them, that's the toolkit issue, Except that mere mortal users suffer from it and a conjunct absence of alternatives. > and users should complain with the toolkit developers I agree those that cause breakage should fix it, but just because it's the right thing to do doesn't mean anyone can expect it to happen. > (or work around the toolkit breakage in whatever way they can). A reasonable workaround is what this bug is asking for.
> > I disagree. > With what exactly? Sorry, I mean I disagree with the idea of working around intentional regression in toolkits by introducing unnecessary complexity in Xorg. > Would it really be bending over backwards to provide a workaround for this particular GTK rudeness? I think so, yes. > Except that mere mortal users suffer from it and a conjunct absence of alternatives. There are alternatives, actually. Also, if mortal users suffer and don't complain or look for alternatives, that's again not an Xorg issue. > A reasonable workaround is what this bug is asking for. There are a number of possible workarounds. * distributions ship a patched version of GTK+3 that does the right thing; * a small LD_PRELOADable library is introduced that fixes the issue; * people stop using GTK+, given how uncooperative and user-unfriendly they are.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/509.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.