frontend: Highlight control dock buttons using style class, Remove NonCheckableButton #11742
+73
−101
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Checkable buttons are troublesome because QAccessible interprets them as checkboxes, and doesn't pass the "clicked" signal to them (see QTBUG-110737). Instead, we only get the "toggled" signal, which also gets triggered by things other than user input (i.e., the button getting changed by the program). Making them uncheckable means that they behave like normal buttons again. To style them, we can just add a class and address them that way. Note that uncheckable here means *actually* not checkable - unlike the cursed NonCheckableButton class previously used that makes a button that *is* checkable ignore the user input (and only allow check state changes via code, effectively making it solely a styling tool).
The NonCheckableButton class was previously used for situations where a *checkable* button was meant to not be checkable by the *user*, but only through code. This was useful mostly as a styling tool (and to confuse developers like me as to what it actually did). The disadvantage is that such a button - a button that is actually checkable (has the checkable attribute) but ignores the user - still gets recognized by QAccessible as a checkable button, which has accessibility issues when used like a normal button (see QTBUG-110737). We can still get the styling effect on *actually* uncheckable buttons by giving them a class, so this widget should not be necessary.
gxalpha
added
Bug Fix
WizardCM
approved these changes
Jan 19, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Checkable buttons are troublesome because QAccessible interprets them as checkboxes, and doesn't pass the "clicked" signal to them (see QTBUG-110737). Instead, we only get the "toggled" signal, which also gets triggered by things other than user input (i.e., the button getting changed by the program).
Making them uncheckable means that they behave like normal buttons again. To style them, we can just add a class and address them that way.
Note that uncheckable here means actually not checkable - unlike the cursed NonCheckableButton class previously used that makes a button that is checkable ignore the user input (and only allow check state changes via code, effectively making it solely a styling tool). The disadvantage is that such a button still gets recognized by QAccessible as a checkable button (and by extension as a checkbox), which has the accessibility issues mentioned above.
We can remove the NonCheckableButton class and simply use the class property for styling.
Motivation and Context
Those buttons being inaccessible via screen readers has bugged me forever, and I previously had a few other attempts at fixing them (all of which had some issues and were never PR'd). This should be the proper fix.
Partially addresses #6200 (#6200 (comment)).
How Has This Been Tested?
Tested that the buttons still work when pressed by the user. Tested that the buttons now work when pressed via a screen reader (macOS VoiceOver in my case), and also that they get recognized as buttons (and not as checkboxes) by the screen reader.
Tested that when using websockets and starting a recording / virtual camera / entering studio mode, the buttons still get the appropriate state.
Types of changes
Checklist: