SUMMARY They will always have Theme.colorSet forced to Header and Theme.inherit forced to true. To be clear, this with all ActionToolBars, not just the global toolbar. This problem also happens with the Default, Material and Fusion styles. I figured out a workaround, but it's awful: https://invent.kde.org/plasma/qqc2-breeze-style/-/blob/master/style/qtquickcontrols/ToolButton.qml STEPS TO REPRODUCE 1. Comment out lines 26-29 2. Compile qqc2-breeze-style 3. Run `QT_QUICK_CONTROLS_STYLE=org.kde.breeze kirigami2gallery` 4. Click on buttons in the global toolbar. OBSERVED RESULT Colors for toolbars and buttons on toolbars are wrong. If you use console.log(), inherit is always true and colorSet is always 6 (Theme.Header) EXPECTED RESULT Colors should match whatever the QQC2 style would normally use. SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20201201 KDE Plasma Version: 5.20.80 KDE Frameworks Version: 5.77.0 Qt Version: 5.15.2 Kernel Version: 5.9.8-2-default OS Type: 64-bit Processors: 4 × Intel® Core™ i7-6500U CPU @ 2.50GHz Memory: 7.6 GiB of RAM Graphics Processor: Mesa DRI Intel® HD Graphics 520
Created attachment 133834 [details] Correct appearance for qqc2-breeze-style
Created attachment 133835 [details] Incorrect appearance for qqc2-breeze-style
Created attachment 133836 [details] Material: Correct (top) and incorrect (bottom) The incorrect style looks better and closer to modern Android, but it's still incorrect.
Created attachment 133837 [details] Default: Incorrect (top) and correct (bottom)
Whoops, I named the Material screenshot incorrectly. Top is incorrect and bottom is correct.
Also, you can't actually see the problem in the Fusion style since it hardcodes more of its button appearance and uses window color for toolbars (except for the gradient, but Kirigami doesn't use QQC2 ToolBars), so disregard what I said about Fusion.
Theme.inherit being true seems like a bug. If you force the color set to something non-default, you're suppose to turn off inheritance, not force it to on. The results will be nonsensical, as you're reporting. I wonder if this is what's causing Bug 429399.
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kirigami/-/merge_requests/184
Git commit fe101efd201255a61e47f387b2aa6d59da829f7c by Marco Martin. Committed on 09/12/2020 at 15:07. Pushed by mart into branch 'master'. Color icons, not buttons when an icon color is set, it tried to color the button and the icon causing often ureadable results. now color just the icon but not the button, giving a less magic behavior. it won't be possible to color non monochrome icons, but that's kinda expected and should be an acceptable compromise Related: bug 429399 M +2 -2 src/controls/ActionToolBar.qml M +0 -6 src/controls/private/PrivateActionToolButton.qml https://invent.kde.org/frameworks/kirigami/commit/fe101efd201255a61e47f387b2aa6d59da829f7c
Unfortunately, that commit didn't completely fix the issue. With qqc2-breeze-style, the buttons have the correct pressed color on the first press, but not on any press after that.
Created attachment 134061 [details] Colors only correct on first press with qqc2-breeze-style