¡Hola Maximiliano! Sorry for the delay. Good news follows!
On Tue, Mar 28, 2017 at 08:43:37PM +0200, Maximiliano Curia wrote: > > > Steps to reproduce invisible text, from a fresh Stretch installation > > where KDE is installed > > > 1. Go to Look and Feel. 2. Select Breeze Dark or Breeze High Contrast > > (or Breeze light for Inkscape) 3. Black on black text in emacs modeline, > > even when running in konsole, without any .emacs.el or .emacs.d/* > > configuration. 4. Green on green text in tooltips from menubar in > > Inkscape (This was tested with Breeze (light, not dark). 5. Almost > > illegible black on dark grey xclock. > > I've only being able to reproduce the inkscape issue. The tooltip shows as > white on white, but I guess it's some uninitialized value, somewhere. > > What's missing here is that you need to restart the session to see some of > the changes applied. Can you please try installing gnome-themes-standard and > testing this back? > > Mmh, testing this again, I needed to reboot my machine to reproduce it, and > to fix it by installing gnome-themes-standard, so maybe there is a cache > file being generated somewhere that needs poking about. One of the most recent batches of KDE-related updates done the trick :-) I had tested having gnome-themes-standard installed and not installed, and it didn't help, and I've confirmed that with these updates it works irregardless of whether or not gnome-themes-standard is installed. > > Hypothesis: KDE is using a method similar to Xresources to apply colour > > scheme without testing for combinations which will produce illegible > > text. > > Indeed, plasma updates the rdb settings [1], how do you expect plasma to > test the colors? > > [1]: > https://sources.debian.net/src/plasma-desktop/4:5.8.4-1/kcms/krdb/krdb.cpp/#L394 Thank you for pointing to the specific line :-) I think something like the following might be useful primarily useful as a test-suite, or possibly in the kcm module itself at the time the colour scheme is applied: You know how the colour picker has a value slider? If that value is extracted from both the foreground and background colour, and the values are compared, then a notification can be generated if the difference between the two values is too small. I'm not sure what the minimum threshold should be for standard themes, but I'm certain that there are already standards for what constitutes high contrast. Actually, I think there might be two ideas here. 1) The kcm module idea, which really only tests for human error 2) Testing for an engine's misimplementation of that colour scheme, in krdb, kde-gtk-config, gnome-themes-standard, et al. #2 I think it would probably require a test application for each supported toolkit. Eg: For each supported toolkit the test suite needs to open a basic program that queries what colours are displayed applied, then uses the logic from #1 to test for sufficient contrast between the foreground & background colours for the following elements: a) Menus b) Text entry areas c) Tooltips. At a minimum QT4 and QT5 (without linking to Plasma libraries), GTK2, and GTK3 ought to be tested, but would be nice if TK was too...even a Wine32 application could be tested. Additionally, a QT5 (with Plasma libraries) one would probably be a good idea to establish a baseline/control. If the check for contrast occurs at multiple points then it would be easier to track down where the contrast problem is occurring (eg: check kcm config, check what krdb is exporting, ask any intermediary layers, ask the toolkit or so some kind or reverse rdb query, if possible). That said, I'm not sure how often the a colour from L432-43 of krdb.cpp gets applied to both foreground and background of an element, or how often values somehow end up unitialised... I haven't checked to see if there was a diff for krdb.cpp. ...not sure if it matters anymore though, as long as there are no regressions On Wed, Mar 29, 2017 at 12:45:50PM +0200, Maximiliano Curia wrote: > Control: tag -1 + upstream > Control: forwarded -1 https://bugs.kde.org/show_bug.cgi?id=355540 > > ¡Hola! > > It seems that the issue is already reported upstream assigned to breeze, but > I'm pretty sure there is something else going on, either no the > kde-gtk-config side or in the mentioned plasma-desktop's krdb side. I think that something in upstream KDE's 5.8.6 (or possibly 5.8.5) fixed this for GTK2 applications. At least, it works for me, with both breeze and breeze dark... Thank you for your patience, and for taking the time to read this. Cheers, Nicholas
signature.asc
Description: PGP signature
