`Border.all()` is a factory constructor and thus not const
constructible. This change adds a `const Border.uniform()`
constructor and makes `Border.all()` delegate to it. This allows
callers to more likely be able to make their widget tree const
constructible.
When submitting data to a server, callers need a callback that will
get invoked after all the individual form fields are saved. If they
have a button that submits the form, they could just do this logic
in the click handler for the button (save the form, then submit to
the server), but if they have more ways than one to submit the form
(i.e. hitting enter while in a text form field), then it becomes
more convoluted and calls for a unified callback that will get
notified when the form is submitted.
-* Inserted an `IconTheme` widget under `CupertinoTheme` to provide a default icon color when using `CupertinoTheme`.
* Changed `CupertinoTheme` to a `StatelessWidget`, to match the implementation of `Theme`
* Changed the nesting order of `Theme`'s sub widgets, to let `Theme.iconTheme` take precedence, so that `Theme`'s behavior is kept as is.
The current repair command for Arch Linux is no longer valid because
`lib32-libstdc++5` had been removed from multilib.
Actually, `lib32-gcc-libs` from core just work.
Also see https://github.com/flutter/flutter/issues/25035
* Fix: ui.PointerChange.remove might contain position change, but we used to expand it into a Cancel and Remove, neither of which allows position change. A Hover event is added, and a test is updated accordingly.
* Fixed the issue where a PointerMoveEvent and a PointerCancelEvent do not receive the correct pressure.
* Refactor the calculation of delta into deltaTo.
This reverts commit ffbb335e35ae7416be98b72779baae6c9bd25b3b.
Reason for revert: flutter driver tests may have bugs in getting
first frame. Revert this until we figure out what happened.
There were 2 possible scenarios in which _handleAppFrame is added more than once as a frame callback. When this happens it is possible that the second invocation will try to access _nextFrame.image when _nextFrame is null and crash. The 2 scenarios are:
Scenario 1
A GIF frame is decoded and a Flutter frame is executed before it's time to show the next GIF frame.
The timer that's waiting for enough time to elapse is invoked, and schedules a callback for the next Flutter frame(here).
Before the next Flutter frame is executed, MultiFrameImageStreamCompleter#removeListener is called followed by ``MultiFrameImageStreamCompleter#addListenerthat is invoking_decodeNextFrameAndSchedule` which is adding `_handleAppFrame` again as a next frame callback.
Scenario 2
removeListener and addListener are called multiple times in succession, every call to addListener can result in another registration of _handleAppFrame to the next Flutter frame callbacks list.
This patch fixes the issue by guarding against a second registration of _handleAppFrame.
