Should fix#22226.
Code introduced in #20890 caused a regression that broke color flooding animations in a BottomNavigationBar that has BottomNavigationBarType.shifting.
The original issue (#19653) dealt with background color changes not occurring until another tab was selected. The result is that the background color instantly changes whenever the state changes and when the widget changes, instead of allowing a new widget to animate the background color change.
* Fixes resulting from audit of issues links
I looked at every link to GitHub in our repo. For cases where we had a TODO that was waiting for a bug to be fixed, and the bug has now been fixed, I applied the pending change. For cases where the link was out of date, I updated the link.
* Update run_test.dart
skip this test again since it failed on linux and macos bots
Move the notch computation from the FAB to the BAB.
The notch in the BAB (bottom action bar) for the FAB (floating action button) was previously kept as part of the FAB's implementation. This was done to keep the shape of the FAB and the shape of the notch coupled.
That approach resulted in a somewhat complex and 'non Fluttery' mechanism for propagating the notch computation from the FAB to the BAB.
This CL uncouples the FAB and the notch computation.
With the new API the BAB computes its overall shape including the notch using a NotchedShape delegate.
This includes multiple breaking changes:
* Scaffold.setFloatingActionButtonNotchFor is deleted.
* The ComputeNotch type is deleted.
* The hasNotch property of BottomAppBar is deleted.
* The notchMargin property of FloatingActionButton is deleted.
Quick migration guide from the previous API:
| Previous API | New API |
| ------------------|-------------|
| BottomAppBar(hasNotch: false) | BottomAppBar() |
| Using a FloatingActionButton with: BottomAppBar() / BottomAppBar(hasNotch: true) | BottomAppBar(shape: CircularNotchedRectangle()) |
| Scaffold.setFloatingActionButtonNotchFor(..) | No longer supported |
This adds an HSLColor class which uses a perceptual color space based upon human perception of colored light (as opposed to HSV, which is based on pigment colors).
You can see the difference in the color spaces here: https://en.wikipedia.org/wiki/HSL_and_HSV
I also added a "within" matcher for both HSLColor and HSVColor that will check if the (floating point) color components are within a certain error.
And tests.
fuchsia_tester.dart still assumes Dart 1. Previously, it ran tests directly
from source, flutter_platform.dart automatically runs a kernel compile when
operating in Dart 2 mode, but this assumes a functional Dart SDK is available
in the artifacts directly, and fuchsia_tester.dart mocks out the artifacts
directory with an empty temp dir.
Remaining work is:
1. Get the frontend server building as a dependency on Fuchsia.
2. Patch fuchsia_tester.dart to use a valid Dart SDK and frontend server.
This also reverts migration to Dart 2 typedef syntax.
This reverts commit 6c56bb2. (#18362)
This reverts commit 3daebd0. (#18316)
Now that Dart 1 is turned off, reapplying my change to turn on the prefer_generic_function_type_aliases analysis option, and fix all the typedefs to Dart 2 preferred syntax.
Also eliminated the unused analysis_options_repo.yaml file and turned on public_member_api_docs in analysys_options.yaml.
No logic changes, just changing the typedef syntax for all typedefs, and updating analysis options.
