[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Color problems [was: Re: KDElibs: KSystemTray: On window close
From:       Sébastien_Laoût "\[temporar\]" <les83plus () free ! fr>
Date:       2004-09-28 10:55:44
Message-ID: 1096368943.2986.13.camel () localhost ! localdomain
[Download RAW message or body]

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
highlight() color.

> 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 
> related.

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 
> invisible.
> 
> 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 
> color:
> darkness = factor * darkness of background color

Yes, you probably are right.
I don't see mistakes.



[prev in list] [next in list] [prev in thread] [next in thread]