You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Allow controls to remain focusable while in disabled state #54877
For desktop platforms (including Web), it makes sense to exclude disabled controls from directional focus.
However, if directional keys are your main form of input, this leads to confusing situations. For example, if a button gets disabled when you activate it, focus will jump to a different control.
Having a parameter to allow focusable controls to maintain focus while in a disabled state would solve this.
Actually, after discussing it with @goderbauer, I think I'm going to try and implement an InheritedWidget that sets the navigation mode for a subtree (much like Directionality does), as he suggested. Then we can use that to determine how to interpret arrow/DPAD keys differently in cases where the navigation mode is DPAD-based. I'll then use that as the switch instead of putting it in ThemeData.
@Hixie Yes, we've decided to support these directional navigation modes in Flutter.
I have a PR to implement this through a MediaQueryData attribute that can be set from the platform if the platform is a TV platform. We don't yet distinguish TV platforms, so for now users of this navigation mode will override it in their app with a MediaQuery widget.
I still need to get more information from the Material Design team about how this will affect some controls (slider, text fields), and whether or not a completely new widget state is needed or not (focused disabled), and what the colors/opacities for all controls would be in that state if so.
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.
Activity
gspencergoog commentedon Apr 16, 2020
Actually, after discussing it with @goderbauer, I think I'm going to try and implement an InheritedWidget that sets the navigation mode for a subtree (much like Directionality does), as he suggested. Then we can use that to determine how to interpret arrow/DPAD keys differently in cases where the navigation mode is DPAD-based. I'll then use that as the switch instead of putting it in ThemeData.
Hixie commentedon Apr 21, 2020
@gspencergoog What's the status of this one? Did we decide to add
tvas a new target platform, or add properties to the relevant widgets, or...?gspencergoog commentedon Apr 21, 2020
@Hixie we are still in the process of deciding. Yesterday I sent Tim and Chris a message about it (and cc'd you).
Hixie commentedon May 19, 2020
@gspencergoog Any updates?
gspencergoog commentedon May 20, 2020
@Hixie Yes, we've decided to support these directional navigation modes in Flutter.
I have a PR to implement this through a
MediaQueryDataattribute that can be set from the platform if the platform is a TV platform. We don't yet distinguish TV platforms, so for now users of this navigation mode will override it in their app with aMediaQuerywidget.I still need to get more information from the Material Design team about how this will affect some controls (slider, text fields), and whether or not a completely new widget state is needed or not (focused disabled), and what the colors/opacities for all controls would be in that state if so.
github-actions commentedon Aug 20, 2021
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.