SUMMARY I've been playing with the color scheme editor, tweaking colors for better accessibility, and have found that Push buttons and comboboxes misuse Selection color for all their states, while checkboxes and radios misuse Focus color for the hover state. I understand that this component may not be the right place for this report, but I really don't know where else to place it. STEPS TO REPRODUCE 1. Set Selection Background to blue, Focus Decoration to green, Hover Decoration to red. 2. Hover over different widgets in the Application Style settings. 3. ... OBSERVED RESULT Radio button and checkbox on hover: green Push button and Combo box on hover: blue Push button and Combo box on focus: blue EXPECTED RESULT Radio button and checkbox on hover: red Push button and Combo box on hover: red Push button and Combo box on focus: green SOFTWARE/OS VERSIONS KDE Plasma Version: 5.23.3 KDE Frameworks Version: 5.88.0 Qt Version: 5.15.2 ADDITIONAL INFORMATION n/a
I'm refiling this to Breeze, as colors work as intended in the Oxygen theme. I need to mention also that the plasma widgets also misuse the colors, in the Breeze theme which should follow the color scheme most widgets just use Selection color for all states.
Can confirm. We should indeed fix this.
Since it's too difficult to make everyone including 3rd parties use Focus and Hover where appropriate in Qt Widgets, well just have to deprecate Focus and Hover and tell everyone to continue using QPalette::Highlight like they already do.
And then rely on the QStyle to modify the highlight color as needed e.g. to provide different styling for "hovered but not focused" and "focused but not hovered" states?
(In reply to Nate Graham from comment #4) > And then rely on the QStyle to modify the highlight color as needed e.g. to > provide different styling for "hovered but not focused" and "focused but not > hovered" states? Yeah, pretty much
Why not just use what we have though? Are there really so many 3rd-party color schemes that do this wrong? If Breeze does, surely we can fix that.
(In reply to Nate Graham from comment #6) > Why not just use what we have though? Are there really so many 3rd-party > color schemes that do this wrong? If Breeze does, surely we can fix that. I was talking about 3rd party apps. When apps have to do a bit of custom painting for their delegates (Qt Widget item delegates can be kind of a mess to implement, unlike Qt Quick) or some other widget, they use QPalette::Highlight. Even KDE apps do this. It doesn't help that KColorScheme is part of a tier 3 framework, so custom Qt Widget components in lower tiers can't use it. With that said, you also cannot guarantee that all 3rd party color schemes (including popular ones) will work well with any decision we make. The simplest answer that is least likely to result in more problems down the line is to just use QPalette::Highlight.
There are a lot of issues surrounding the customization of color schemes that aren't likely to be resolved unless we make a new color scheme system.