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

Olaf Jan Schmidt ojschmidt at
Wed Sep 29 14:00:17 BST 2004

Hash: SHA1

[David Johnson, Mittwoch, 29. September 2004 06:48]
> I have to step up to the defense of style writers everywhere.

I have not accused the style writers. I simply pointed out a bug. This bug
is most likely not caused by the style writers, but rather in kdelibs.

> The problem isn't that the styles are erroneous, but rather that they
> were designed for lighter colored schemes. This isn't as trite as it
> sounds.

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.

> It's because 3D effects work best with lighter midtones. This is true
> regardless of any errors Qt might have in computing 3D colors.
> The 3D effects don't work for darker color schemes because shadows are
> always darker, and highlights always lighter, than the surface they are
> on. To change this would be to create an unpleasant embossing effect
> for most 3d styles.

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.

> There are several styles that work with dark schemes (like "Dark
> Blue"), but to expect them to work in the presence of the "black
> singularity" is asking too much.

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 I wrote an application that only worked for some of the styles, then
you would rightly call my application broken. If someone writes a style
that doesn't work with a number of accessibility settings, then the style
is also broken. This doesn't mean that the author is a bad person, it
simply means that there are bugs that makes KDE almost unusable for a
number of users, and that should therefore be fixed.

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

> > 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?


- --
Olaf Jan Schmidt, KDE Accessibility Project
KDEAP co-maintainer, maintainer of

Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see


More information about the kde-core-devel mailing list