* add a FAB NotchMaker to ScaffoldGeometry
* add a notchMaker to FloatingActionButton
* Initial implementation of BottomAppBar
Mainly includes the notch making logic.
Not yet tested as currently there is no way to make the FAB and the BAB
overlap, once #14368 to lands we could add unit tests to the
BottomAppBar as well.
* use a closeable for clearing the FAB notchmaker
* Use engine-built dart sdk
* Download dart-sdk from engine
* Move up deps to fix dart sdk constraint problem
* Update update_dart_sdk.ps1 for Windows
* Fix tests so they pass analysis
* More types for tests
* Roll engine
* Update dart sdk stamp location in flutter.bat
* Add newline
Adds a ScaffoldGeometry class and ValueNotifier for it.
A scaffold's ScaffoldGeometry notifier is held in the _ScaffoldState, and is passed to _ScaffoldScope.
New ScaffoldGemometry objects are built and published to the notifier.
* Roll engine to pre-dart roll
* Roll engine to pick up updated dart
* Apply Map changes
* Move to dev.22
* Fix some analysis issues
* Silent analyzer
* More consts
* More const massaging
* Yet more const massaging
* Yet more const massaging
* Use nonconst()
Use mockito in the Dart 2 compliant way:
* use typed(...) in appropriate places to wrap matchers like any;
* don't pass matcher directly into the calls - use `argThat(matcher)`.
Also rename paintColorMatcher to hasColor to match how other similar
functions are named and how the code reads.
* Use explicit types for onClick handler in diagnostics_test.
This test formats it to string and expects exact match.
Before this change onClick had type () => dynamic in Dart 1 and () => Null in
Dart 2.
* Fix strong mode issues in packages/flutter/test/material/dropdown_test.dart
Pass explicit type argument to renderObjectList(...) in expressions like
List<RenderBox> l = tester.renderObjectList(...).toList();
Dart 2 mode inference is not strong enough to infer RenderBox as a type argument
fto renderObjectList and passes RenderObject instead, which later leads to
runtime check failures (because List<RenderObject> is not List<RenderBox>).
* Fix strong mode issues in packages/flutter/test/material/theme_test.dart.
Pass type argument explicity to widgetList. Dart 2 type inference can't infer
it by itself.
* Fix strong mode issue packages/flutter/test/widgets/unique_widget_test.dart
Pass correct type argument to GlobalKey.
* Fix type annotation in packages/flutter/test/material/app_test.dart.
pushNamed returns Future<Object> not Future<String>.
Using a void list literal in this case is valid and correct, and will be
required for dart 2.
Note: void can be inferred here, but followed the lints to write it
explicitly even though that's arguably a bit weird in this case and less
backwards compatible.
Note: also fixes a bug wherein bottom media padding was applied even in the
presence of persistent footer buttons.
The material spec states that the keyboard should be positioned on top
of any bottom navigation bar or persistent footer buttons widget(s).
We no longer inset the bottom of bottom navigation bars / persistent
footer buttons by the bottom viewInset.
Body content bottom (and the bottom of bottom sheets) is now determined
by the greater of:
1. bottom view inset (the keyboard height)
2. bottom elements (nav bar, footer buttons)
relative to the window max-Y.
0672055a72ff1265b2aedb037f2848455318f22a changed the Material widget to
always use Paths for representing the outline.
These paths are later used for clipping and drawing a shadow.
This changed introduced a performance regression, see:
https://github.com/flutter/flutter/issues/14403
We did not expect a path that is a rounded rectangle to be less
performant than a rounded rectangle, as Skia should be able to tell the
path is just a rounded rectangle.
Until we find a solution for this regression, we keep using RRect when
we can represent the shape with it.
In a scaffold, snackbars are positioned above the BottomNavigationBar
and/or PersistentBottomButtons, if present. In such cases, they should
not apply bottom media padding to their widget sub-tree.
For backward compatibility we keep supporting specifying the shape as a
combination of MaterialType and borderRadius, and we just use that as a
default when shapeBorder is null.
To cleanup the implementation if shapeBorder was not specified we just
translate the specified shape to a shapeBorder internally.
I benchmarked paint, layout and hit testing, with the specialized shape
clippers vs. the equivalent path clippers and did not see any
significant performance difference.
For testing, I extended the clippers/physicalShape matchers to match either the
specialized shape or the equivalent shape.
* Move the splitting of licenses to an isolate
This improves (from horrific to terrible) the performance of the
license screen. It also introduces a feature in the foundation layer
to make using isolates for one-off computations easier.
The real problem that remains with this, though, is that transfering
data between isolates is a stop-the-world operation and can take an
absurd amount of time (far more than a few milliseconds), so we still
skip frames.
More work thus remains to be done.
* - Add profile instrumentation to the isolate compute() method
- Add profile instrumentation to the LicensePage
- Add profile instrumentation to the scheduleTask method
- Make scheduleTask support returning a value
- Make the license page builder logic use scheduled tasks so that it doesn't blow the frame budget
