Color problems [was: Re: KDElibs: KSystemTray: On window close dialog]

[David Johnson]

On Wednesday 29 September 2004 06:00 am, Olaf Jan Schmidt wrote:

> It is perfectly fine to write styles that work for only a part of the
> settings in KDE, but then they shouldn't be part of kdelibs and
> definately shouldn't be default. Anyway, I think the styles
> themselves are OK, it is only the 3D algorithm in Qt and/or kdelibs
> that is broken.

If all you're asking is to fix the bug in Qt, then I'm all in favor of 
it. Heck, I'll even help you code or test it. But while it will improve 
most styles, I doubt it will push them into the level of accessibility 
I think you want.

> If you have a white background, then you can still see the frames.
> Using a similar technique, you can make sure that they are visible
> for dark backgrounds as well, without removing the 3D look of the
> colors in between. There is no good reason why the algoriothm should
> return black as a the lighter colour of black. If the algorith
> returned dark gray, then everything would be fine.

With a true white background you're losing half the frame/bevel 
information for most styles. A true black background would be the same 
even with your suggested fix.

> I don't think it is asking too much to expect all parts of KDE to
> work for disabled people. I do believe, however, that it is asking
> too much of disabled users to work around bugs in KDE by changing a
> lot of independent settings.

If accessibility means that KDE users cannot have Plastik as their 
default style, even though they have been requesting it in hordes for 
over a year now, then I would have to say you are indeed asking too 
much.

These aren't bugs in KDE. You have identified a real bug in Qt, but that 
fix won't make all styles instantly accessible. That's because the 
styles aren't incorrect. You simply cannot draw a shadow on a black 
background and see it. Even with your suggested fix you're drawing very 
dark gray highlights around black widgets. That's very difficult to see 
with the best of eyesight!

I have taken special care with my styles to make sure they work with 
darker color schemes. But very dark backgrounds are a special corner 
case. It's one that almost demands a separate substyle. That's twice 
the work.

If (!verydarkbackground)
 // code to draw the widget normally
 // ...lighter highlights and darker shadows
else
 // code to draw the widget using a black background
 // ... light highlights AND light shadows AND drop the gradients

> > The solution is not to blame the styles, but rather to create a new
> > style for use in situations that need high contrast dark color
> > schemes.
>
> This is the usual reply, but no one has yet offered to write this
> style. Another problem is that users with low vision will not know
> which style to select, so KDE will still appear broken for them. This
> is why at least the styles in kdelibs need to be fixed - if a fix in
> the algorithm is not enough, which I expect.

I would offer to do this, but I simply have too much stuff on my plate 
right now. Since I'm not too proud to turn down mercenary work, offers 
of monetary compensation would do a lot to change my mind. (Heck, last 
time I threw up that challenge someone accepted, so why not do it 
again? The worst that can happen would be howls of derisive 
laughter...)

Sidenote: If users with low vision won't know which style to select, how 
did they know to select a color scheme that wouldn't work with the 
default style? Your hypothetical problem could be solved, it seems to 
me, by making it simple to select an accesible style/scheme from the 
Desktop Settings Wizard. Then you can kill two birds with one stone.

> > > 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
> >
> > Not quite accurate, but I get your point. I banged my head against
> > this one in the past as well.
>
> Do you see any problems with this suggestions for intermedate
> colours?

After digging into the code I found that your suggestion doesn't reflect 
what's happening. The palette is built in 
KApplication::createApplicationPalette() using QColor::light() and 
QColor:dark(). So we're already using the inverted algorithm for 3D 
effects. QColor::light() multiplies HSV value by the lightness factor 
and QColor::dark divides HSV value by the darkness factor.

The problem is only with black (zero value). One possible solution is to 
make an arbitrarily low HSV value the "floor" for the QColor 
calculations. It could be fixed in KApplication, but that won't catch 
all the instances of light() and dark().

-- 
David Johnson
___________________
http://www.usermode.org