Summary: | When setting dark color scheme, disabled menu items are completely illegible | ||
---|---|---|---|
Product: | [Frameworks and Libraries] kdelibs | Reporter: | Leif Huhn <lb.kdebugzilla> |
Component: | kstyle | Assignee: | Karol Szwed <gallium> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | CC: | andresbajotierra |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | openSUSE | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Leif Huhn
2003-03-17 09:52:27 UTC
The bug is in kdelibs/kdecore/kapplication.cpp, at around line 1718 QColorGroup disabledgrp(disfg, background, background.light(highlightVal), background.dark(lowlightVal), background.dark(120), background.dark(120), base); QColorGroup colgrp(foreground, background, background.light(highlightVal), background.dark(lowlightVal), background.dark(120), baseText, base); baseText is the color of a normal menu entry. It is stored in the QColorGroup colgrp. The analagous entry for disabledgrp is background.dark(120). This just makes the color darker, without any regard to it being lighter. It would be nice if this color entry was given the same treatement as the text color for buttons further down (~line 1743): QColor disbtntext = buttonText; disbtntext.hsv( &h, &s, &v ); if (v > 128) // dark button, light buttonText - need a darker disabled buttonText disbtntext = disbtntext.dark(lowlightVal); else if (disbtntext != black) // light buttonText, dark button - need a lighter disabled buttonText - but only if !black disbtntext = disbtntext.light(highlightVal); else // black button - use darkgrey disabled buttonText disbtntext = Qt::darkGray; Note that simple, as that entry isn't actually used. Why isn't it used? There seems to be no rhyme or reason to how KDE Styles choose their colors. Yeah, because there is no "official" definition for what is to be used for what. And the isuse here is that the grey out effect uses colors that are bevel intermediate ones. That's why this is quite tricky -- it's hard to get the proper effect which people expect and guarantee contrast. Sorry on the slowness w/this BTW -- real life getting in the way. Yes, I think this is the same as reported in bug#96145 where I added some screenshots showing this problem. I've been trying to use a black window (and buttons) background for about 8 years (at that time I was still using windows), but couldn't get to any usable configuration due to hard coded colors :(or automatic system color behaivour - in this case). So still have to use dark grey :( I think the mental problem here is trying to emulate a white paper (light reflective device - or a passive element) using a computer screen (light source device - or the active element). If each pixel lights to show something on the screen, why sould we have 90% of the pixels lighted on to it's maximum (white) to read text on the lighed off pixels :(black). Corection to previous post: I just did a comment to the bug#96145 but the screenshots I've posted in this topic: http://kde-artists.org/main/forum/index.php?topic=362.0 Here using: Qt: 4.5.1 (qt-copy 958974) KDE: 4.2.71 (KDE 4.2.71 (KDE 4.3 >= 20090428)) kdelibs svn rev. 960693 / kdebase svn rev. 960693 on ArchLinux i686 - Kernel 2.6.29.1 Disabled widgets colors are now selectable/customizable so you if you are experiencing this you can revert it, even on plain black themes. |