Color problems [was: Re: KDElibs: KSystemTray: On window close dialog]
david at usermode.org
Thu Sep 30 05:25:20 BST 2004
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
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
// code to draw the widget normally
// ...lighter highlights and darker shadows
// 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
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
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().
More information about the kde-core-devel