-
Notifications
You must be signed in to change notification settings - Fork 29.8k
Implement focus traversal for desktop platforms, shoehorn edition. #30040
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
I could have had less direct breakage by just requiring that it be set before needing it, using the new setter on FocusNode, but that just seemed far too likely to cause people to forget to set it, and cause problems with traversal when someone was allowed to add one to the tree with no context set. It felt like making them supply it drove home that they needed to set it, but I also dislike having multiple paths to setting it (via the constructor argument to |
1abb0dc to
b2b947d
Compare
...tter_tools/ide_templates/intellij/.idea/runConfigurations/manual_tests___focus.xml.copy.tmpl
Outdated
Show resolved
Hide resolved
cf8a4c1 to
adb2081
Compare
|
I removed some of the "Add on" features for this PR to move them to another PR. I didn't create the other PR because it still includes this one, but you can see the diffs here. |
5e55551 to
05fcaf1
Compare
de85581 to
23bd495
Compare
23bd495 to
329abaf
Compare
a6194cf to
8c0ef66
Compare
goderbauer
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM modulo some nits
(Although I still wish we would clean up the API more and remove some of the cruft that's just there for backwards compatibility)
|
What about changing focus when pressing TAB on an iOS or Android simulator? Will you move to the next input field? |
|
@vanlooverenkoen, this PR itself doesn't provide the key bindings for that to happen, but it, along with #30076, will provide the mechanism for changing focus to next and previous (and in an axis direction) widgets. I have other PRs in the works that will add focus handling to material and cupertino widgets, and we will be producing a keyboard shortcut mechanism that will eventually enable what you're asking for. In summary, we're working on it, but there are a lot of moving parts to be completed. |
21fe5ee to
a6276f7
Compare
…tion. (flutter#30040)" This reverts commit 4218c0b.
|
@gspencergoog We would like to be able to to traverse from the widget tree into an overlay and back. Is such a thing possible with the current API? In our case, we're trying to create an auto-complete dropdown menu, we want to traverse into the dropdown contents, and back, as you would on a normal desktop control (https://i.imgur.com/xZCv3xm.gifv). Happy to create a new issue, just wanted to check in case it is already a supported use case. |
Description
Implement focus traversal for desktop platforms, including re-implementing the existing focus manager and focus tree. This shoehorns all of the functionality of my focus traversal changes into the existing API, with minimal breakage.
This implements a
Focuswidget that can be put into a widget tree to allow input focus to be given to a particular part of a widget tree.It incorporates with the existing FocusScope and FocusNode infrastructure, and has minimal breakage to the API, although
FocusScope.reparentIfNeededis removed, replaced by a call toFocusAttachment.reparent(), so this is a breaking change.There are several followup PRs to this one, that will be layered on top: #30076 (see diff here) and #30077 (see diff here)
Related Issues
Addresses #11344, #1608, #13264, and #1678
Fixes #30084
Fixes #26704
Checklist
Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes (
[x]). This will ensure a smooth and quick review process.///).flutter analyze --flutter-repo) does not report any problems on my PR.Breaking Change
Does your PR require Flutter developers to manually update their apps to accommodate your change?
Yes, this is a breaking change:
FocusScopeNodes must now be attached to the focus tree usingFocusScopeNode.attach, which takes a context and an optionalonKeycallback, and returns aFocusAttachmentthat should be kept by the widget that hosts theFocusScopeNode, because of the need to make sure that the focus tree reflects the widget hierarchy.FocusScope(context).reparentIfNeededwill callreparenton theirFocusAttachmentinstead.