- 27 Jan, 2021 2 commits
-
-
Greg Spencer authored
This fixes a subtle bug in the focus traversal that would leave unfocusable FocusTraversalGroup nodes in the list of sorted nodes to be traversed, causing an assert to fire if you nested a FocusTraversalGroup in another one and made its children unfocusable.
-
Alexandre Ardhuin authored
-
- 20 Nov, 2020 1 commit
-
-
Greg Spencer authored
Adds Navigator.maybeOf to replace calling Navigator.of(context, nullOk: true), and removes the nullOk parameter. Also changes Navigator.of to return a non-nullable value, and removes many (120!) instances of the ! operator, reducing the possible places where a null dereference could occur.
-
- 29 Oct, 2020 1 commit
-
-
Greg Spencer authored
This removes the nullOk parameter from Focus.of, FocusTraversalOrder.of and FocusTraversalGroup.of, and creates maybeOf equivalents for each. The of methods now return non-nullable values, and the maybeOf equivalents return nullable values.
-
- 12 Oct, 2020 1 commit
-
-
Darren Austin authored
-
- 09 Jul, 2020 1 commit
-
-
Kate Lovett authored
-
- 11 Jun, 2020 1 commit
-
-
Alexandre Ardhuin authored
* add language version 2.8 in packages/flutter * enable non-nullable analyzer flag
-
- 03 Jun, 2020 1 commit
-
-
Greg Spencer authored
-
- 08 May, 2020 1 commit
-
-
Pierre-Louis authored
* Expose includeSemantics option to RawKeyboardListener * Revert "Expose includeSemantics option to RawKeyboardListener" This reverts commit 684edccfb0bacb358285b34b7a6dafd45a070ca7. * Set includeSemantics to false * Expose includeSemantics for RawKeyboardListener * Add test
-
- 05 May, 2020 1 commit
-
-
Greg Spencer authored
-
- 01 May, 2020 1 commit
-
-
Greg Spencer authored
This adds an ExcludeFocus widget that prevents widgets in a subtree from having or obtaining focus. It also adds the ability for a FocusNode to conditionally prevent its children from being focusable when it isn't focusable (i.e. when canRequestFocus is false). It does this by adding an descendantsAreFocusable attribute to the FocusNode, which, when false, prevents the descendants of the node from being focusable (and removes focus from them if they are currently focused).
-
- 10 Apr, 2020 1 commit
-
-
Alexandre Ardhuin authored
* replace simple Container(w & h) with SizedBox * address review comments * address review comments
-
- 13 Feb, 2020 1 commit
-
-
Greg Spencer authored
This re-lands #49235 with the addition of includeSemantics flag on the Focus widget so that the FocusTraversalGroup can create a Focus widget without affecting the semantics tree. The FocusTraversalGroup uses the Focus widget to create a grouping of descendants for traversal, but doesn't actually participate in focus (canRequestFocus is always false), so we don't want it to add a Semantics widget in that case, since that can cause semantics changes. The canRequestFocus attribute can also be used when a widget is disabled, so we do sometimes want to include Semantics even if that is false, but not in the case where it is always false, as for FocusTraversalGroup. - Added a test to make sure that FocusTraversalGroup doesn't add any semantics information.
-
- 12 Feb, 2020 1 commit
-
-
Greg Spencer authored
This reverts commit 8ef5e2f0 because it breaks some semantics tests.
-
- 11 Feb, 2020 1 commit
-
-
Greg Spencer authored
This change adds a way to provide explicit focus order for a part of the widget tree. It adds FocusTraversalPolicyGroup, which in many ways is similar to DefaultFocusTraversal, except that it groups a widget subtree together so that those nodes are traversed as a group. DefaultFocusTraversal doesn't work as one would expect: If there is more than one DefaultFocusTraversal inside of a focus scope, the policy can change depending on which node was asked to move "next", which can cause unexpected behavior. The new grouping mechanism doesn't have that problem. I deprecate DefaultFocusTraversal in this PR. It also adds OrderedFocusTraversalPolicy, which is a policy that can be supplied to FocusTraversalPolicyGroup to set the policy for a sub-tree. It looks for FocusTraversalOrder inherited widgets, which use a FocusOrder to do the sorting. FocusOrder has two subclasses: NumericalFocusOrder (which sorts based on a double), and LexicalFocusOrder, which sorts based on a String. As part of doing this, I refactored the way FocusTraversalPolicy is implemented so that it has more default implementation methods, and exposes a new protected member: sortDescendants, which makes it easier for developers to make their own policy subclasses: they only need to implement sortDescendants to get a new ordering behavior, but can also still override any of the default implementation behaviors if they need different behavior. I was able to do this without breaking the API (AFAICT).
-
- 27 Nov, 2019 1 commit
-
-
Ian Hickson authored
* Update project.pbxproj files to say Flutter rather than Chromium Also, the templates now have an empty organization so that we don't cause people to give their apps a Flutter copyright. * Update the copyright notice checker to require a standard notice on all files * Update copyrights on Dart files. (This was a mechanical commit.) * Fix weird license headers on Dart files that deviate from our conventions; relicense Shrine. Some were already marked "The Flutter Authors", not clear why. Their dates have been normalized. Some were missing the blank line after the license. Some were randomly different in trivial ways for no apparent reason (e.g. missing the trailing period). * Clean up the copyrights in non-Dart files. (Manual edits.) Also, make sure templates don't have copyrights. * Fix some more ORGANIZATIONNAMEs
-
- 20 Nov, 2019 1 commit
-
-
Greg Spencer authored
Before this change, it was possible to move the focus onto a control that was no longer in the view using focus traversal. This changes that, so that when a control is focused, it makes sure that if it is the child of a scrollable, that the scrollable attempts to keep it in view. If it is already in view, then nothing scrolls. When asked to move in a direction, the focus traversal code tries to find a control to move to inside the scrollable first, and then looks for things outside of the scrollable only once the scrollable has reached its limit in that direction.
-
- 06 Nov, 2019 1 commit
-
-
Greg Spencer authored
Currently, we listen to keyboard events to find out which keys should be represented in RawKeyboard.instance.keysPressed, but that's not sufficient to represent the physical state of the keys, since modifier keys could have been pressed when the overall app did not have keyboard focus (especially on desktop platforms). This PR synchronizes the list of modifier keys in keysPressed with the modifier key flags that are present in the raw key event so that they can be relied upon to represent the current state of the keyboard. When synchronizing these states, we don't send any new key events, since they didn't happen when the app had keyboard focus, but if you ask "is this key down", we'll give the right answer
-
- 30 Oct, 2019 1 commit
-
-
Erick (CptBlackPixel) authored
Fixes directional focus traversal when there are no available nodes to traverse to.
-
- 17 Oct, 2019 1 commit
-
-
Greg Spencer authored
In #42533, I disabled the up/down arrows for focus navigation in text fields, but we thought of a better way to do it, so this is that better way. This change reverts the other change, and instead it tests the context of the node in the action to see if it's an EditableText node. If so, then it doesn't do the navigation action.
-
- 10 Oct, 2019 1 commit
-
-
Greg Spencer authored
This attempts to reland #40186 and #41220, that were reverted in #41945. The main modifications from the original PRs are that I predefine the shortcuts and actions maps instead of defining them inline in the build function, and I use a new mapEquals to do a deep comparison so that we don't rebuild modified things if the contents of the map haven't changed. I also eliminated an operator== and hashCode that were defined on the Actions widget, since widgets shouldn't have those. (it's too bad though: I get an 85% speedup if we leave this in! Too bad it prevents rebuilding of the children...) Fixes #40101
-
- 04 Oct, 2019 1 commit
-
-
Greg Spencer authored
-
- 02 Oct, 2019 1 commit
-
-
Greg Spencer authored
This adds the default shortcuts and actions for keyboard-based focus traversal of apps. This list of shortcuts includes shortcuts for TAB, SHIFT TAB, RIGHT_ARROW, LEFT_ARROW, UP_ARROW, DOWN_ARROW, and the four DPAD keys for game controllers (because the DPAD produces arrow key events). It doesn't yet include functionality for triggering a control (e.g. SPACE, ENTER, or controller buttons), because that involves restructuring some of the Flutter controls to trigger animations differently, and so will be done in another PR (#41220)
-
- 26 Sep, 2019 1 commit
-
-
Greg Spencer authored
The proposed change will change focus handling when pushing and popping routes so that the FocusScopeNode for the route receives focus when pushed, and that the FocusScopeNode in the navigator receives focus when the route is popped. This means that the last setFirstFocus call on the scope is used to determine which control actually receives focus. When the focus scope receives focus, it traverses its children, trying to find a non-scope node that is the "first focus" of itself or a child node. This is a breaking change, because the focus behavior has changed. If you push a route after this change, and had a 'first focus' set on a widget via FocusScopeNode.setFirstFocus, it won't currently receive focus immediately, but after this change it will. Similarly, if you pop a route after this change, the focus will go back to where it was before the route was pushed, which is correct, but different from what happens now.
-
- 12 Aug, 2019 1 commit
-
-
Greg Spencer authored
This improves the ability to debug focus manager issues. It's not meant to be used by developers unless they're debugging problems with the focus manager itself.
-
- 17 Jul, 2019 1 commit
-
-
伯言 authored
FocusTraversalPolicy keep the previously visited node to avoid hysteresis. But even if the visited focus has been disposed, FocusTraversalPolicy will still use it to requestFocus, which will cause FocusManger to get an abandoned node to get the focus.
-
- 28 May, 2019 1 commit
-
-
Greg Spencer authored
Replacing the algorithm for finding the first focusable item in the focus tree. Somehow it was a kind of gibberish before, and really didn't work or make sense.
-
- 10 May, 2019 1 commit
-
-
Greg Spencer authored
This implements a DefaultFocusTraversal widget to describe the focus traversal policy for its children, defined by a FocusTraversalPolicy object from which custom policies may be created. Pre-defined policies include widget-order traversal, "reading order" traversal and directional traversal.
-