Bug 438763 - Some checkboxes are by default in half-state (tristate)
Summary: Some checkboxes are by default in half-state (tristate)
Status: CONFIRMED
Alias: None
Product: systemsettings
Classification: Applications
Component: kcm_kwineffects (show other bugs)
Version: 5.22.0
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords: usability
Depends on:
Blocks:
 
Reported: 2021-06-16 18:27 UTC by postix
Modified: 2023-12-01 20:12 UTC (History)
7 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
Screenshot (24.90 KB, image/png)
2021-06-16 18:27 UTC, postix
Details

Note You need to log in before you can comment on or make changes to this bug.
Description postix 2021-06-16 18:27:54 UTC
Created attachment 139406 [details]
Screenshot

SUMMARY

As you can see in the screenshot, some of the effects are in a half-state, though this doesn't make sense as their state is in reality binary.
The systems are set up freshly and those settings haven't been changed yet.

Toggling results in "half activated" -> "fully activated" -> "off" -> "fully activated" -> ... so kinda repairs it. 


SOFTWARE/OS VERSIONS
Fedora 34 but also

Operating System: openSUSE Tumbleweed 20210614
KDE Plasma Version: 5.22.0
KDE Frameworks Version: 5.82.0
Qt Version: 5.15.2
Kernel Version: 5.12.9-1-default (64-bit)
Graphics Platform: X11
Comment 1 Nicolas Fella 2021-06-16 23:18:06 UTC
Judging by the code the half-state means that the setting is set to default and the default is dynamically determined. Some effects are en/disabled based on GPU features
Comment 2 David Edmundson 2021-06-17 11:27:31 UTC
Yes, this is working completely as intended. 

The UI could be clearer. I don't have immediate ideas on that.
Comment 3 Nate Graham 2021-06-17 18:23:30 UTC
Tri-state checkboxes should only be used for tree views to indicate that only some of a parent item's children are checked. In all other circumstances, it is wrong because the meaning of the "half-checked" state is context-specific cannot be communicated to users--which is the exact problem being described here.

Idea: actually check and uncheck it dynamically depending on whether it is supported by your GPU, with a message in the list item indicating this ("This effect has been automatically disabled because may not work properly with with your graphics hardware.")