Version: (using Devel) Installed from: Compiled sources - wrong text colors: checkbox is button, should be window - groupbox is view, should be window - combobox is view, should be button (non-editable only) - tab is button, should be window - arrows: are all button, should be view in spins, window for scrollbars - might be better fixed in KStyle? - progress bars: should use selection for filled, button(?) for not-filled... seems to be OK but using hover for fill bg? ...not sure if button is really the color we want, but that's releasable; the hover color OTOH is likely to break with even some shipped color schemes
SVN commit 819315 by boemann: use correct colorrole for groupbox title CCBUG:156518 M +1 -0 oxygen.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=819315
SVN commit 819318 by boemann: fix colorrole of checkbox and tabs CCBUG:156518 M +22 -0 oxygen.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=819318
I tested SVN (from yesterday) and there are still some color role violations, see http://www.kde-look.org/content/show.php/CheckColorRoles?content=90034 for a screenshot.
working on it. Thanks a lot for the color-scheme on KDE look. Very helpfull.
ok. I think I fixed all glitches. See screenshot. Feel free to re-open if new ones are found.
Created attachment 37675 [details] system settings for oxygen style, with dedicated color scheme (from Skulptor) used to identified wrong color roles.
In the left icon view, the color role for the selected item text is wrong. The text should be brown (as the 70% in the progress bar), not blue. Thanks for the fixes :)
Christoph Feck wrote: > https://bugs.kde.org/show_bug.cgi?id=156518 > > > > > > --- Comment #7 from Christoph Feck <christoph maxiom de> 2009-10-20 17:58:44 --- > In the left icon view, the color role for the selected item text is wrong. The > text should be brown (as the 70% in the progress bar), not blue. Thanks for the > fixes :) > > That's actually an interesting one. The TreeView selected text color is the correct one if the tree view has focus. It is incorrect (as in the screenshot) only if it does not have focus. And in fact it is not true for "all" tree views. (kdialog for instance is just fine, and so is dolphin, konqueror, kate. But none are correct in kcm.). I was originally suspecting kstyle or qcommonstyle,cause other styles have the exact same issue (cleanlooks, plastique, and ... well ... skulpture) but in fact now I'd rather suspect some ill-formed itemDelegate. I'll be digging some more to see if I can pin that down, but as far as oxygen colors are concerned, as far as I can tell I think they're ok now. Oh and also I noticed that deferent are used for qt applications with respect to KDE. I wonder whether it comes from Qt re-interpreting either the style, or the color scheme (both being set in Qt config to "system defaults"), or both ... Hugo
That's actually a really interesting one, because I cannot reproduce it :) With current trunk I always get the brown text on selected items, with both Oxygen and Skulpture, with all focused and unfocused views and windows. Another bug: the toolbar expander is hardcoded to black with Oxygen, it should be the WindowText color.
SVN commit 1039149 by hpereiradacosta: Fixed color role for editable combobox arrow, and for tree view expander arrow. CCBUG: 156518 M +20 -6 oxygen.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1039149
SVN commit 1039162 by hpereiradacosta: Use single arrow (and not double), and correct colorrole, for menubar and toolbar extension icon, for consistency with the rest of oxygen CCBUG: 156518 M +9 -20 oxygen.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1039162
*** Bug 214386 has been marked as a duplicate of this bug. ***
*** Bug 216774 has been marked as a duplicate of this bug. ***
please reopen: flat buttons have no background color (being flat), but they get the “button” text color instead inheriting the text color from their parent ui element. you can watch this on every flat button, e.g. the “maximum page” button on okular’s bottom bar, and some kpackagekit buttons, too. also, there are at least two different applications with custom widgets which don’t follow the color rules: * kpackagekit (bug 253990) * amarok (bug 229452) maybe these should block this bug? or should we create a new tracking bug (description: “some applications have custom widgets which don’t follow the color rules”), which is blocked by these both? either way, this bug should be reopened, because the flat buttons seem to be globally wrong.
to comment #14, Flat button color definitely is an issue with oxygen (working on it) As for the two application bugs you mention, no they should not appear here. They are 'oxygen-independent', ans there is nothing we can do about it. They should stay as application bugs and be fixed by the application devs.
hpereiradacosta * r1191695 workspace/trunk/KDE/kdebase/workspace/kstyles/oxygen/oxygenstyle.cpp: Fixed text and arrow color role for flat buttons and comboboxes. CCBUG 156518