All slivers must start with Sliver (or CupertinoSliver).
All widgets must have a key argument.
Also, some minor tweaks here and there to style and docs.
Instead, if the surface is 0x0 semantics will just generate one root semantics node with size of 0x0. The node will have no children because all children are invisible and (except for the root node with this change) invisible children are dropped.
They should fail, because we don't have real support yet.
Also, make the debug override work in release builds, so that people
on those platforms have a workaround.
A significant amonut of code uses defaultTargetPlatform, so it's
currently impossible to run most apps on Windows. This adds a mapping
from Windows as a host to Android as a target, paralleling the
macOS->iOS and Linux->Android mappings.
This allows more use of Windows as a host platform (e.g., for testing,
as in issue #17768).
* fixed segmented control golden test
* fixed segmented control golden test
* added cursorWidth, cursorRadius
* added default value for cursorWidth based on Apple specs
* test default cursorWidth
* removed cursorHeight stuff
* added functionality to keep cursor from blinking
* cursor width and radius is configurable + tests
* changed goldens repo version in goldens.version
* working version of configurable cursor (erased debugKeepCursorOn)
* minor changes
* docs
* changed textfield test that was failing due to new default cursorwidth
* added default value of cursorwidth in RenderEditable
* only run golden file tests on Mac
* cursor tests
* the tests are actually there now
* weak warning fixed
* switching to Linux
* changed default cursorWidth: 2.0 -> 1.0
* assorted changes, including changing text field test
* re-paint -> re-layout when changing cursorWidth
This logic is described in the test as looking for a scroll ending
very close to a new page, but in fact its behavior is more like
"very close to a page to the right": if we're not very, very close
to any page, it will pick the page to the left, not an old page.
There's no reason this should be left-right asymmetrical.
Instead, pick the nearest page.
In practice, the case where this makes a difference never arises when
the scroll runs undisturbed to completion; but when the user taps on
the page to hold or drag, the scroll will be interrupted before it
gets within tolerance of a particular page, and this case does arise.
This fixes a glitch that is hard to trigger without time dilation,
but is quite conspicuous with it:
* Open a tab view with at least 4 tabs, e.g. the Buttons screen
of the gallery (with "Animate Slowly" on.)
* Starting at tab 0, tap tab 2.
* When the animation is nearly complete, tap the page a couple
of times, as if to drag it around to scroll. Then let the
page view settle ballistically toward page 2.
* Before it finishes, tap tab 3.
* Suddenly page 1 fills the view, replacing page 2, before we
scroll from there to page 3.
With this fix, the animation in the last step moves smoothly from
where we are when it starts onward to page 3.
* Revert "manual rollback of of 18530 (#18531)"
This reverts commit 3f79f8cba5425e964f05fc79331dc5ff4b82c22f.
* Fix the offset calculation
* Add a unit test
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 |
