Repository navigation
Use tristate checkbox engine changes - #111032
Conversation
|
Need to wait for next engine roll |
1b82960 to
4f74f1b
Compare
There was a problem hiding this comment.
Just curious, when can this be null? If never, should this be non-nullable?
There was a problem hiding this comment.
My thought process was to leave it to default to null when the widget has no checked state or is not tristate, like how checked is nullable and is not set when the widget has no check state.
There was a problem hiding this comment.
I'd tweak the comment to clarify the non-null case as that's not readily apparent. Effectively: non-null if this is a checkbox, true if this is a tristate checkbox in the mixed state, false otherwise.
Perhaps something like:
If non-null, indicates that this subtree represents a checkbox or similar widget with a "checked" state. If true, this is a tristate checkbox in the mixed state.
This must be false when [Checkbox.tristate] is false.
There was a problem hiding this comment.
Should this modify SemanticsFlag.isChecked? If no, why not?
There was a problem hiding this comment.
Also, should isChecked modify SemanticsFlag.isCheckStateMixed?
There was a problem hiding this comment.
In all cases I can imagine, they should be mutually exclusive when true, so the question is just whether we want to enforce that internally in the SemanticsConfiguration
There was a problem hiding this comment.
There was a problem hiding this comment.
The thing is about asserting that exclusivity is that it would create an issue for the tests that ensure all flags are supported, as they work by setting all accessibility flags and making sure they are each reflected in the resulting semantics. If we do make this assertion, those tests would need to change in a manner that I'm not yet sure on how.
There was a problem hiding this comment.
Agreed that generally we should be making liberal use of assertions to assert any invariants, especially since they're documented invariants.
Can you point to tests that would be broken by this? Could be it's the tests that need updating now that we're modelling new state.
There was a problem hiding this comment.
Agreed that generally we should be making liberal use of assertions to assert any invariants, especially since they're documented invariants.
Can you point to tests that would be broken by this? Could be it's the tests that need updating now that we're modelling new state.
|
@cbracken https://github.com/flutter/flutter/blob/394f762c0683491a1807158aa817bd5088697919/packages/flutter/test/widgets/custom_painter_test.dart#L417 and https://github.com/flutter/flutter/blob/394f762c0683491a1807158aa817bd5088697919/packages/flutter/test/widgets/semantics_test.dart#L552 would break with this, as they test by expecting a semantics node with all possible flags set. If two flags assert mutual exclusivity, we cannot possibly create a semantics node that matches that expectation. One option that may coexist with the assertions is to manually remove the mixed flag from the expected semantics to avoid the clash. |
|
Sounds like the test needs to be updated since all flags true is no longer a valid state. |
|
@cbracken The latest commit addresses this, please take a look. |
There was a problem hiding this comment.
Make the assert a precondition check at the top of the setter to prevent it from getting into a bad state if the user violates an invariant.
Co-authored-by: Chris Bracken <[email protected]>
Typo fix in comment Co-authored-by: Loïc Sharma <[email protected]>
c7571b2 to
904c05e
Compare
| key: const Key('a'), | ||
| container: true, | ||
| explicitChildNodes: true, | ||
| // flags |
There was a problem hiding this comment.
Is this comment necessary?
There was a problem hiding this comment.
Are you referring to //flags? This was already present in the earlier definitions in this test function, so it was copied to the modified instance created here.

Sends the mixed checkbox state for tristate checkboxes to the engine in order to update semantics properties. Previously the half-checked/mixed/indeterminate state of a tristate checkbox was not read properly by screen readers.
Addresses #110107
Pre-launch Checklist
///).If you need help, consider asking for advice on the #hackers-new channel on Discord.