Color problems [was: Re: KDElibs: KSystemTray: On window close dialog]
Sébastien Laoût [temporar]
les83plus at free.fr
Tue Sep 28 11:55:44 BST 2004
Le mar 28/09/2004 à 11:23, Olaf Jan Schmidt a écrit :
> I disagree. Hardcoding colors is an accessibility No-No.
> In this case, it has the following problems:
> 1. What if you have a red background in kicker?
Do you know someone who have it (root doesn't count)?
Please see the screenshot: it's clearly better in "most" cases.
But I fully agree with you: this should be in the color theme.
Currently I haven't any other solution so I haven't done the revert to
> 2. What if you have a green background and are color-blind?
By default, the kicker is gray or blue.
I don't think (but I can be wrong) blue/red is a problem (perhapse they
both seem dark for color-blind people...).
Lot of peoples keep (blue) defaults, and I think color-blind people
aren't so crazy to choose a green or red background color.
But one more time, it's to explain the red color, that is the better
solution (I think) for now.
> Would it be possible to add a "Warning Color" to the color schemes for KDE
> 3.4, or would this break binary compatibility? Otherwise a solution might
> be to use two colors instead of only red.
I'm also 100% for this addition.
Oh yes, two colors...
But how to switch from red to the other?
I will think about it.
> There are similar problems with hardcoded black. KDE is currently hardly
> usable for people who need white text on black background because of low
> vision. This needs a lot of independent fixes in KDE. I will discribe
> more problems later and only mention two problems here, because they are
I also noticed this problem this night.
I will replace the hardcoded black with foreground() color.
It fixe the problem.
> None of the styles works correctrly using a white on black color scheme.
> We either need to add a style frame color to the color scheme, or the
> styles need to check for the background color and optionally use white
> instead. At least the default style for KDE 3.4 should be fixed, but it
> would be better if none of the styles had this bug.
> A related problem needs to be fixed in Qt: The 3D effect currently only
> really works if the background color is light. If the background color is
> black, both 3D effect colors are also black, meaning that frames are
> The currently algorithm for both shadow color and light effect color is
> something like:
> brightness = factor * brightness of background color
> This can be fixed by using an inverted algorithm for the light effect
> darkness = factor * darkness of background color
Yes, you probably are right.
I don't see mistakes.
More information about the kde-core-devel