Summary: | Disabled ToolButton actions/buttons don't render their text as disabled | ||
---|---|---|---|
Product: | [Frameworks and Libraries] frameworks-kirigami | Reporter: | Aleix Pol <aleixpol> |
Component: | general | Assignee: | Marco Martin <notmart> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | a.stippich, ahiemstra, aleixpol, bugseforuns, kde, nate, noahadvs, notmart, uhhadd |
Priority: | NOR | ||
Version: | 5.84.0 | ||
Target Milestone: | Not decided | ||
Platform: | Other | ||
OS: | Linux | ||
Latest Commit: | https://invent.kde.org/frameworks/kirigami/-/commit/bf3b2d41708e6331ed26aa280609b8f39f3f7772 | Version Fixed In: | 6.7 |
Sentry Crash Report: | |||
Attachments: |
wrong qqc2-desktop
material properly disabled |
Description
Aleix Pol
2021-02-19 15:50:21 UTC
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 |