While debugging this I found that buttons' labels don't change the font colour. https://bugs.kde.org/show_bug.cgi?id=433002 It works fine with material and org.kde.breeze, so the issue is here. I'll upload screenshots so you can see how I test it.
Created attachment 135906 [details] wrong qqc2-desktop
Created attachment 135907 [details] material
Created attachment 136040 [details] properly disabled Does that still happen? on a minimal test case there's how a disabled toolbutton looks here
I think this might be an issue specific to Kirigami ActionToolBar. In the Discover screenshots, the "Make default" button is being created from a Kirigami Action that is a child of an ActionToolBar. https://invent.kde.org/plasma/discover/-/blob/master/discover/qml/SourcesPage.qml#L45 I've had trouble with buttons generated by ActionToolBar not having their colors set correctly before (e.g., https://bugs.kde.org/show_bug.cgi?id=429972).
I can't reproduce with an actiontoolbar with same code as discover. i would guess it ight be the binding between enabled of action to enabled of button being broken on some occasions
Yes, the way Discover injects actions into its ActionToolbar could be be the problem, causing broken bindings as Marco suggests. I can't reproduce the issuer with a generic disabled QQC2 toolbutton styled with the qqc2-desktop style. Moving to Discover
It might be a problem of how Discover does it, but I don't see how we're really breaking any rules in there. So I can try other ways of doing it in Discover but ultimately the problem will eventually arise in other Kirigami apps if we don't understand it properly.
I think this is actually an ActionToolbar problem. You can see the issue in Kirigami Gallery too: Go to the ActionToolBar page, click on the info button in the top-right corner, and see that the text "HIG" at the bottom of the popup is rendered as active, even though it's disabled.
*** Bug 438772 has been marked as a duplicate of this bug. ***
According to Bug 440799, this affects plain toolbars too, so not a Kirigami issue. Moving.
*** Bug 440799 has been marked as a duplicate of this bug. ***
it's a problem in Kirigami.Theme: * a Theme instance has its own set of colors if it does *not* inherit * the set of color of disabled stuff should be different from enabled * if a non inherit one is disabled, it will take colors from the parents that are not disabled seems that the optimizations in theme can't really be made working correctly
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kirigami/-/merge_requests/1614
Git commit bf3b2d41708e6331ed26aa280609b8f39f3f7772 by Marco Martin. Committed on 25/09/2024 at 09:37. Pushed by mart into branch 'master'. Use disabled text colors also for inherit-ing Theme instances * a Theme instance has its own set of colors if it does *not* inherit * the set of color of disabled stuff should be different from enabled * if a non inherit one is disabled, it will take colors from the parents that are not disabled Change to behave as non inherit when the quickitem of this theme is disabled and colorGroup is not Disabled M +50 -0 autotests/tst_theme.qml M +3 -0 src/platform/basictheme.cpp M +11 -2 src/platform/platformtheme.cpp https://invent.kde.org/frameworks/kirigami/-/commit/bf3b2d41708e6331ed26aa280609b8f39f3f7772