The PlatformViewsService listens for `viewFocused` calls on the
platform_views system channel and fires a callback that focuses the
focus node for the relevant AndroidView widget.
This implements focus and hover handling for Material buttons. It inserts Focus widgets into the tree in order to allow buttons to be focusable via keyboard traversal (a.k.a. TAB traversal), and Listener widgets into the InkWell to allow the detection of hover states for widgets.
Addresses #11344, #1608, and #13264.
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.
This changes Listener to trigger enter/move/exit in all Listeners below the pointer, not just the leaf region (the first region hit). This is because we need to allow listeners to be nested so that, say, a widget that handles changing color on hover, but also is wrapped in a Tooltip (that handles hover) can trigger both actions, not just one.
To that end, I added a findAll to Layer, similar to the existing find method that was previously used. It returns an iterator over annotated layers which match the given data type.
Since the findAll is implemented as returning an Iterable (and is sync*), I re-implemented the find routines as just returning the first result from findAll, since that should be just as efficient, and would then prevent duplication in the implementation.
I recently added some code to keep hover events from being propagated when a mouse wasn't attached. While that works, there are times when it can fire callbacks during the building of other components, since they can now be called from detach/attach. This is not ideal, since it will assert then. This changes the code so that it won't update the annotations during attach/detach, but also won't push the annotation layer unless a mouse is connected, achieving the same result as before, but with better semantics.
The basic problem is that in the detach for RenderPointerListener, it would detach the annotation, which could cause onExit to be called on the annotation, since the widget was disappearing under the mouse, and thus needs to receive an onExit, but that onExit might be (and probably will be) calling setState, which marks the owning widget as needing to be built, sometimes when it already has been.
The fix creates a new _ListenerElement that overrides activate and deactivate in order to tell the render object ahead of the detach that it might be detached, and so the onExit gets called before the detach instead of during it.
In addition, I now avoid scheduling more than one check for mouse positions per frame.
* Add Flag to determine if pixels is set by viewport during disposal
* Add TODO to remove nested TabBarView workaround once unnecessary build/dispose issues are resolved
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.
* Revert "Revert "Add buttons to gestures (#30339)" (#31801)"
This reverts commit 8fd7fa492aaad0d0d4aa062d71b1ecba8b0d4f44.
* Synthesise kPrimaryButton for unknown devices
* Change TestPointer to a better API
## Description
Make `_RenderCustomClip`'s `clipBehavior` non-final so we can update it during `updateRenderObject`. This will support `clipBehavior` changes in hot reload.
## Related Issues
Fixes#30863
## Tests
I added the following tests:
* ClipRect updates clipBehavior in updateRenderObject
* ClipRRect updates clipBehavior in updateRenderObject
* ClipOval updates clipBehavior in updateRenderObject
* ClipPath updates clipBehavior in updateRenderObject
* PhysicalModel updates clipBehavior in updateRenderObject
* PhysicalShape updates clipBehavior in updateRenderObject
* Callbacks of tap, long press, drag, and double tap GR respond to only primary events.
* Add "secondary" callbacks to tap.
* Recognizers only compete on events if there are any related callbacks.
* Add "kSecondaryButton" constant.
It looks like the documentation for UiKitView has been copy-pasted from AndroidView or so.
This PR fixes the word 'Android' to 'iOS' for the `creationParams`.
- Fixed the bug where CupertinoRefreshControl doesn't work in the gallery demo on Android.
- Updated documentation on CupertinoRefreshControl
- Added comments to the gallery demo
- Added concrete examples to ScrollPhysics
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 #1678Fixes#30084Fixes#26704
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 #1678Fixes#30084Fixes#26704
