¡Hola Nicholas! El 2017-04-15 a las 21:33 -0400, Nicholas Steeves escribió:
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.
Good to hear. I'm still seeing white on white tooltips in inkspace when inkscape is restored from a previous session. I guess that the colors for non qt apps are applied after launching the restored apps.
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
This is out of the scope of the Debian maintainers work, also you are assuming that a high contrast is mandatory, when there are a number of highly popular themes that provide a "low contrast". Anyway if you are planning on implementing this, please consider contacting upstream to coordinate your work.
Thank you for your patience, and for taking the time to read this.
You are welcome. Happy hacking, -- "Whenever possible, steal code." -- Tom Duff Saludos /\/\ /\ >< `/
Attachment:
signature.asc
Description: PGP signature