usability regression: >3.16.x results in too small GTK3 app UI fonts in KDE/TDE/IceWM
- From: Felix Miata <mrmazda earthlink net>
- To: gtk-devel-list gnome org
- Subject: usability regression: >3.16.x results in too small GTK3 app UI fonts in KDE/TDE/IceWM
- Date: Thu, 28 Jul 2016 02:36:54 -0400
<http://fm.no-ip.com/SS/KDE/gtk3mousetype-1607b-168.jpg> demonstrates the problem
in a 168 DPI environment, plus records various software environment states. The
higher the DPI, the bigger the problem. At 168 DPI, UI text in GTK3 builds of
Firefox is downright painful to try to see. Looking at the screenshot it's clearly
evident UI fonts in GTK2 Firefox 45 match native UI elements, while in Firefox 47,
UI fonts are a tiny fraction of what they should be.
<http://fm.no-ip.com/Auth/dpi-screen-window.html> is the URI loaded in the Firefox
Windows in the screenshot.
As I do not use Gnome and do not have an account at https://bugzilla.gnome.org/
I thought it best to ask here if there is something I don't know about to work
around this regression. Karl Tomlinson suggested privately before closing
https://bugzilla.mozilla.org/show_bug.cgi?id=1269274 that this commit is the
regression point:
<https://git.gnome.org/browse/gtk+/commit/?id=bdf0820c501437a2150d8ff0d5340246e713f73f>
I've confirmed the problem exists on multiple installations of *buntu, Mageia,
Fedora, Debian and openSUSE with various versions of KDE, TDE and IceWM, and
on Intel, AMD/ATI and NVidia gfxchips. GTK3 Firefox in older installations that
provide GTK3 versions <3.18 behaves as expected, same as GTK2 Firefox. Gimp
2.8.16 as provided by openSUSE Tumbleweed inherits UI fonts as expected. There
are no other GTK apps besides SeaMonkey that I'm familiar with. SeaMonkey GTK3
builds (e.g. 2.44) misbehave the same as Firefox GTK3 builds.
To reproduce, simply try to globally configure Xorg's logical display density,
either through xrandr in a startup script, or through /etc/X11/xorg.con*, then
start a virgin user KDE[1], TDE[2] or IceWM session using either startx, TDM
or KDM. In every local case, Xft.dpi is purposely set null so that display
density in Xorg is globally configured automatically and uniformly by either
xrandr or xorg.conf*, subject to override on an individual user basis only.
I'm not a developer, just a tester. I don't do any kind of building. Applying
patches is outside my realm of competence and interest.
[1] In KDE 4 or 5 aka Plasma, a virgin user session may override the global
setting unless preconfigured via kdedrc thus:
[Module-kscreen]
autoload=false
[2] https://wiki.trinitydesktop.org/
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
[
Date Prev][Date Next] [
Thread Prev][Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]