Files
thoughtsync/android
bvandeusen 39170b715c
Desktop (Tauri) / Windows installer (cross-compiled) (push) Successful in 3m5s
Desktop (Tauri) / Tauri desktop (Linux) (push) Successful in 5m23s
Desktop (Tauri) / Update manifest (push) Successful in 4s
Android / Kotlin + Rust (debug APK) (push) Successful in 7m15s
android: leaving the composer keeps the note, and the board loses its dead space
Two things the operator hit on a real device.

**Capture threw work away.** Every exit from the compose sheet except Save
discarded it — tapping the board behind, swiping down, back, backgrounding the
app, and rotating the phone. That is the wrong default anywhere and the worst
possible one here: a sheet that loses a typed thought because you touched
outside it teaches people not to trust the app with a thought, and capture is
the one place this product cannot afford that.

Now every way out saves, which is the shape the editor already settled on. The
difference is that capture also has to be abandonable — tapping + and changing
your mind is normal — so Discard exists and is the only path that loses
anything. It is called Discard rather than Cancel because "cancel" means "undo
what I am doing", which is precisely what leaving no longer does; the word would
have described the one button it is not attached to. An empty draft needs
neither and is simply dropped: a blank note nobody asked for is worse than none.

Backgrounding persists but does NOT close an empty sheet. Someone who tapped +
and got distracted should find the composer where they left it.

Rotation was losing it twice over: the draft was `remember`, and so was the flag
saying the sheet is open. Both are `rememberSaveable` now, along with the sync
screen's — the editor never had the bug because the note it sits on lives in a
view model, and these were the only screen state that did not.

`FlushOnStop` moves out of NoteEditorScreen into its own file; the editor and
the capture sheet want the identical thing for the identical reason, and it was
about to be copied.

**The board had a centimetre of nothing above the search field.** `SearchBar`
applied `statusBarsPadding()` inside a `Scaffold` whose content padding already
carries the system-bar insets — `ScaffoldDefaults.contentWindowInsets` is
`systemBarsForVisualComponents`, checked in the material3 sources rather than
assumed. So the status bar height was reserved twice on the first screen anyone
sees. Insets get consumed once, by whichever component owns the edge.
2026-08-19 19:39:40 -04:00
..
2026-08-19 11:18:24 -04:00