Version: (using KDE 4.0.83) Installed from: SuSE RPMs OS: Linux Some widget styles (including Plastique and Windows) do not support hover decoration. It is always in the color settings module without any comment that it is not supported by some styles so I think the user can expect that it works. Also, with those styles, the Dolphin breadcrumb navigation bar elements do not have a mouseover effect which is confusing because virtually every clickable text has some kind of mouseover effect in KDE (at lest with, for example, the Plastique style).
Plastique and Windows are Qt styles, not KDE styles. You could file an enhancement request at Qt Software's task tracker. The only non-Oxygen KDE style is Phase, which is not in kdelibs. So this maybe needs to be reassigned?
Could a Qt style use a color setting which is currently only used by KDE styles? As no Qt style uses the hover decoration color, it is not a Qt but a KDE setting, isn't it?
Qt already reads KDE color settings, but not the hover colors, as Qt has no use for these (as you noticed).
KDE implements an enhanced color system, which has a fallback QPalette for applications and styles that are not aware of KColorScheme. I checked if it would be possible to maintain different QPalette instances for the different states of the widgets in order to set the Highlight color to the hover color, but this would require major hacks with event filters. As such, I am marking this as WONTFIX. To support the additional hover colors, it is necessary to use KColorScheme instead of QPalette directly. If you see a style or application that does not honor the additional colors, please ask for this feature there. For built in Qt styles, such as Plastique, please file the bug report to http://bugreports.qt.nokia.com/ For the Phase style, this one does not need a hover color; hovering indication is done by subtly increasing the brightness of the button color.
There is at least two cases like this, additional functionality being implemented via styles (the other, much more serious one being described in Bug 181017 and Bug 182726). I don't know muck about Qt and KDE programming so I might be wrong but IMHO the proper implementation of these things would be one of the following: 1. Ask Qt developers to include the feature. It would benefit them too after all. 2. This would benefit KDE applications only: create subclasses, KDE versions of the affected Qt widgets (which is AFAIK already done in many cases), make KDE applications use them and implement the KDE specific functionality in them (with allowing the style to have a say in the appearance if it is a visual thing and the style is aware of the KDE specific functionality). 3. Create first-class KDE styles out of the official Qt styles by subclassing them and implementing the KDE specific functionality in them. I suspect that the 3rd solution is the simplest. But having functionality which simply doesn't work with certain configuration is a usability problem and you cannot rely on people using KDE styles without having a classical Windows-like style as a KDE style nor having ported Plastik as a KDE style. "For built in Qt styles, such as Plastique, please file the bug report to http://bugreports.qt.nokia.com/" I don't quite understand: how could I ask Qt developers to include support for a KDE specific functionality in their styles without first asking them to implement the functionality itself in standard Qt?
"how could I ask Qt developers to include support for a KDE specific functionality in their styles without first asking them to implement the functionality itself in standard Qt?" Yes, you can ask them to get that functionality into Qt, e.g. by adding more color roles to QPalette. That is the reason why I gave you the link. If QPalette has support for the new color roles, KDE can fill in the values from system settings so that pure Qt styles can use them.