The Linux platform channels sample makes a call to the libupower function `up_client_get_devices`, which was deprecated in libupower 0.99.8 in favour of `up_client_get_devices2`.
In order to build both for users on older versions of libupower, such as 0.99.7, which ships with Ubuntu 18.04 (Bionic), as well as users on newer versions where `up_client_get_devices` is deprecated, this adds a preprocessor check and selects the function available on the host system on which the build takes place.
The Flutter devicelab prod bots have been migrated to Ubuntu 20.04 LTS (Focal) which includes 0.99.11, but the trybots are still in the process of being migrated. This allows the build to work on both, and makes life easier for users running on a variety of Linux distributions.
No tests are added or modified since `up_client_get_devices` and `up_client_get_devices2` have the same semantics.
See: https://upower.freedesktop.org/docs/UpClient.html#up-client-get-devices
See: https://gitlab.freedesktop.org/upower/upower/-/blob/master/libupower-glib/up-version.h.in
Note: the `UP_CHECK_VERSION` macro has been around since 2010 (13 years ago), when DKP was forked into libupower. 27fada20be
Issue: https://github.com/flutter/flutter/issues/127611
Fixes https://github.com/flutter/flutter/issues/117627
### Behavior changes:
1. If fade in/fade out animation is already in progress, hiding/showing the tooltip will immediately take effect without waiting for `waitDuration`.
2. A PointerDownEvent that doesn't become a part of a "trigger" gesture dismisses the tooltip, even for hovered ones.
3. The OverlayEntry is now updated only when the previous tooltip was completely dismissed. This can be fixed by OverlayPortal but I'm not sure what the correct behavior is.
This example was incorrectly throwing away results from a query when multiple queries were pending at once. Thanks to @sun-jiao in https://github.com/flutter/flutter/pull/127019#issuecomment-1552347037 for pointing this out.
I also added a quick `Text` widget explaining what to do to use the examples. Since there are only three small possible `options`, it's easy to type into the field and not get any results and wonder what's wrong.
## Background
The Windows runner has a race at startup:
1. **Platform thread**: creates a hidden window
2. **Platform thread**: launches the Flutter engine
3. **UI/Raster threads**: renders the first frame
4. **Platform thread**: Registers a callback to show the window once the next frame has been rendered.
Steps 3 and 4 happen in parallel and it is possible for step 3 to complete before step 4 starts. In this scenario, the next frame callback is never called and the window is never shown.
As a result the `windows_startup_test`'s test, which [verifies that the "show window" callback is called](1f09a8662d/dev/integration_tests/windows_startup_test/windows/runner/flutter_window.cpp (L60-L64)), can flake if the first frame is rendered before the show window callback has been registered.
## Solution
This change makes the runner schedule a frame after it registers the next frame callback. If step 3 hasn't completed yet, this no-ops as a frame is already scheduled. If step 3 has already completed, a new frame will be rendered, which will call the next frame callback and show the window.
Part of https://github.com/flutter/flutter/issues/119415
See this thread for alternatives that were considered: https://github.com/flutter/engine/pull/42061#issuecomment-1550080722
This is a proof of concept for renaming SlottedMultiChildRenderObjectWidgetMixin to SlottedMultiChildRenderObjectWidget and making it a concrete class.
I also made SlottedContainerRenderObjectMixin generic instead of being specialized to RenderBox.
I don't think this is something we can easily automigrate, but we may not need to, I don't know how common this is...
This PR does a couple of things!
https://user-images.githubusercontent.com/16964204/231897483-416287f9-50ce-468d-a714-2a4bc0f2e011.mov
Fixes#20819Fixes#41910Fixes#121419
### Adds ScrollController.onAttach and ScrollController.onDetach
This resolves a long held pain point for developers. When using a scroll controller, there is not scroll position until the scrollable widget is built, and almost all methods of notification are only triggered when scrolling happens. Adding these two methods will help developers gain access to the scroll position when it is created. A common workaround for this was using a post frame callback to access controller.position after the first frame, but this is ripe for issues such as having multiple positions attached to the controller, or the scrollable no longer existing after that post frame callback. I think this can also be helpful for folks to debug cases when the scroll controller has multiple positions attached.
In particular, this also resolves this commented case: https://github.com/flutter/flutter/issues/20819#issuecomment-417784218
The isScrollingNotifier is hard for developers to access.
### Docs & samples
I was surprised we did not have samples on scroll notification or scroll controller, so I overhauled it and added a lot of docs on all the different ways to access scrolling information, when it is available and how they differ.
1. Add iOS and macOS migration to mark "last upgraded" Xcode version to 14.3 to prevent `Update to recommended settings` warning.
2. Update iOS and macOS templates to same.
3. Update iOS template to set `BuildIndependentTargetsInParallel` to YES as suggested. I didn't add a migration for this since it seems like a minor optimization and I don't think it's worth a potentially botched/corrupted migration.
4. Run all example/integration test project to see migrator work.
5. Add some missing test projects to the build shard since I noticed they were missing and I had to build those manually outside `SHARD=build_tests`.
Fixes https://github.com/flutter/flutter/issues/125817
See https://github.com/flutter/flutter/pull/90304 for Xcode 13 example.
Most of these imports were never appropriate. The `test_api` package was never intended for use in `_test.dart` files.
Where possible move imports to `matcher`, otherwise move them to `test` or `flutter_test`.
Leave uses of `test_api` from `flutter_test` library code.
When swapping out delegate of selectioncontainer, if the newly passed in delegate doesn't have any selectable content(which is usually the case), the selectioncontainerstate will notify all of the listeners. One of the listener would be SelectionRegistrant._updateSelectionRegistrarSubscription, and since it doesn't have content, it would remove itself from the listener which causes concurrent modification
