- 21 Aug, 2019 2 commits
-
-
Greg Spencer authored
This reverts commit a11d7314 because of a regression in flutter_gallery_ios32__transition_perf's 90th_percentile_frame_build_time_millis. Fixes #38860.
- 16 Aug, 2019 1 commit
-
-
Greg Spencer authored
This adds a FocusHighlightMode to the FocusManager that switches based on the type of input that has recently been received. The initial value is based on the platform, but is updated as soon as user input is received. There is also a FocusHighlightStrategy enum so that the developer can change the strategy to a fixed value if needed. The default is to automatically detect the mode based on the last type of user input. If they use a mouse or keyboard, it shows the focus highlights. If they use a touch interface, then the highlights disappear. This is consistent with the way that Android and Chrome work. The controls still receive focus, only the display of the highlight changes. Text fields show the focus highlight regardless of the focus highlight mode.
-
- 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.
-
- 09 Aug, 2019 2 commits
-
-
Michael Klimushyn authored
This reverts commit 92ef2b9c. This requires either runApp() or WidgetsFlutterBinding.ensureInitialized() to have been called before using any MethodChannels. Plugins broadly rely on MethodChannels and right now there's no general requirements that they be constructed within the runApp call, so the ecosystem breakages from this are broader than originally thought. Reverting for now.
-
adazh authored
-
- 28 May, 2019 1 commit
-
-
Harry Terkelsen authored
* Deprecates `BinaryMessages` in favor of a default instance of `BinaryMessenger`, called `defaultBinaryMessenger` * Platform channels use the `defaultBinaryMessenger` for their binaryMessenger default argument.
-
- 21 May, 2019 1 commit
-
-
Greg Spencer authored
This just fixes up some comments for DefaultFocusTraversal, and fixes a minor bug when setting the onKey on a FocusNode on creation before attaching to it.
-
- 01 May, 2019 1 commit
-
-
Greg Spencer authored
In #31614, I added an unfocus() to FocusNodes to allow giving up of focus, but it only worked on the primary focus. This changes that so that it will unfocus the entire chain, not just the primary focus. Now, if you call unfocus() on a FocusNode or FocusScopeNode, and their hasFocus returns true, then after calling unfocus(), it will return false. Before this change, it would only do that if hasPrimaryFocus was also true. This also fixes a bug in the way setFirstFocus was implemented, making it conform more to the behavior of the previous implementation. It has simplified logic in reparent, and in when it requests focus for scope nodes that have had setFirstFocus called on them.
-
- 25 Apr, 2019 1 commit
-
-
Greg Spencer authored
This re-lands the Focus changes in #30040. Correctness changes in routes.dart, and removes the automatic requesting of focus on reparent when there is no current focus, which caused undesirable selections. Addresses #11344, #1608, #13264, and #1678 Fixes #30084 Fixes #26704
-
- 23 Apr, 2019 1 commit
-
-
Greg Spencer authored
This reverts commit 4218c0bc.
-
- 22 Apr, 2019 1 commit
-
-
Greg Spencer authored
Implements focus traversal for desktop platforms, including re-implementing the existing focus manager and focus tree. This implements a Focus widget 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.reparentIfNeeded is removed, replaced by a call to FocusAttachment.reparent(), so this is a breaking change: FocusScopeNodes must now be attached to the focus tree using FocusScopeNode.attach, which takes a context and an optional onKey callback, and returns a FocusAttachment that should be kept by the widget that hosts the FocusScopeNode. This is necessary because of the need to make sure that the focus tree reflects the widget hierarchy. Callers that used to call FocusScope(context).reparentIfNeeded in their build method will call reparent on a FocusAttachment instead, which they will obtain by calling FocusScopeNode.attach in their initState method. Widgets that own FocusNodes will need to call dispose on the focus node in their dispose method. Addresses #11344, #1608, #13264, and #1678 Fixes #30084 Fixes #26704
-