search

lxqt / lxqt-qtplugin

LXQt Qt platform integration plugin
https://lxqt.github.io
GNU Lesser General Public License v2.1
24 stars 14 forks source link

Workaround for Qt's poor handling of some dark palettes #70

Closed tsujan closed 3 years ago

tsujan commented 3 years ago

Qt implicitly assumes that the base and window colors don't have a high contrast with each other and uses the latter to get some colors related to the former, resulting in unreadable texts:

  1. Qt sets the disabled base color to the window color. The current patch leaves the disabled base color to be equal to the enabled one (disabled widgets are distinguished from enabled ones in other ways) because the window color may have a high contrast with it and make disabled texts unreadable.
  2. Qt gets the alternate base color (used by some item views) by mixing the base and window colors. The patch gets it by decreasing/increasing the lightness of the base color a little.

Closes https://github.com/lxqt/lxqt-qtplugin/issues/69

NOTE: If window and base colors have a high contrast with each other, symbolic SVG icons might be white/black on white/black backgrounds. Nothing can be done by us for avoiding that — KDE devs made the same mistake that was hidden inside Qt — but, IMO, we shouldn't disallow this kind of palette (→ UNIX philosophy).

luis-pereira commented 3 years ago

@tsujan How can one test it? Manipulate the palette ?

tsujan commented 3 years ago

@luis-pereira By making a palette like that of https://github.com/lxqt/lxqt-qtplugin/issues/69, namely, a dark window color but a light (white) view color. Then, the first screenshot of that report shouldn't happen with the patch.