* StackNavigationView: animate a fraction of its width, not a fixed 4000px offset
Showing a view started its slide from the hide state's 4000px offset rather than the
view's width, so a pushed view stayed off-screen for its first ~240ms and then crawled
through the tail of a 0.5s decay. Hiding headed for 4000px over 5s, cut short at the width.
* Animate `slide`, a fraction of the view's width, so both directions move right away.
* Both use a 0.35s `ExpDecay {d1: 0.80, d2: 0.97}` and finish when that animation ends.
* Drop the widths `StackNavigation` pushed into its views, and the notes/calendar
workarounds that re-applied the hide target at runtime.
* StackNavigationView: start a slide on the frame after it's requested
A slide's clock started on the same frame as the first draw of the view it reveals,
which can be slow (e.g., a timeline building its items), so the next frame jumped
far along the curve. Starting it one frame later lets that draw land first.
* platform: a dismissed soft keyboard drops the ShowTextIME ops still queued -- a focused TextInput re-pushes ShowTextIME on every draw, so a show queued by the frame drawn just before the dismissal could still be in platform_ops; drained after Android's ResizeTextIME-closed path cleared last_ime_config, it re-opened the keyboard the user had just closed. text_ime_was_dismissed now removes those stale shows before queuing HideTextIME.
Ported from makepad/makepad#1235.
(cherry picked from commit 4b3ef69054)
* Android: keep the soft keyboard up when focus moves from one text input to another
The input losing focus hid the keyboard right away, and the input gaining focus asked
to show it a frame later. That hide started a real hide animation whose "closed" report
counted as the user dismissing the keyboard, which dropped the new input's show, so the
keyboard went down and stayed down until the input was tapped again.
Now a hide waits until after the next draw, and an input asking for the keyboard in that
draw cancels it.
* Animator: solve `Ease::Bezier` to a tight tolerance
It stopped solving once x was within `t / 200`, so steep stretches (e.g., the end of
`cubic-bezier(0.3, 0, 0.8, 0.15)`) were off by up to 0.02 and could step backwards
between frames. A fixed 1e-7 tolerance with a few more iterations keeps every curve
within about 1e-6 of exact, and monotonic.
* Animator: add `Ease::Emphasized`, the curve Android uses for activity transitions
Material's emphasized easing (Android's `fast_out_extra_slow_in`) is a two-part path,
so it can't be a single `Bezier`: it's the emphasized-accelerate curve up to 40% at a
sixth of the time, then the emphasized-decelerate curve. A test checks it against
points sampled from Android's path data.
* StackNavigationView: slide with Android's activity transition timing
Both directions now take 450ms with `Ease::Emphasized`, the duration and curve Android
uses between activities. The 0.35s `ExpDecay` started at full speed and then crawled
through a long tail, which felt too fast and uneven for a full-screen slide.
---------
Co-authored-by: ymote <151983+ymote@users.noreply.github.com>
711521dbfa