Phase 3, third step, of docs/material-design-conformance.md. Nine screens and a dialog
carry text fields. One of them called `imePadding()`; the audit had said seven screens, and
was wrong about that too.
`Scaffold`'s `contentWindowInsets` defaults to `systemBars`, which does **not** include the
ime, so a `Scaffold` on its own does nothing about a keyboard covering the field being
typed into. `Modifier.imePadding()` on the Scaffold lifts the whole screen, which is the
standard shape and the one that needs no per-field handling.
Eight screens get it: AddArtifact, AddChapter, AddDialect, TranslateChunk,
ChatRoomCreation, CreateProfile, SignIn, WriteNewNote. Each carries a one-line comment
saying why, since a bare modifier in a Scaffold argument list is the kind of thing that
gets deleted in a cleanup.
**ChatRoomMessagingScreen is deliberately not one of them**, and the reason is now written
where somebody would look for it. Its composer already reserves its own bottom inset with
`navigationBarsPadding()`. Adding `imePadding()` to the Scaffold as well would pad twice
while the keyboard is up, because the ime inset already covers the navigation bar area that
row is separately reserving. Getting that combination right wants a device with a keyboard
open, not a compiler, and it is the one screen where the existing code shows signs of
having been tuned by hand.
**Not device-verified, and worth saying so plainly.** The emulator's account boots to a
populated home screen, and reaching any of the eight means several hops through
onboarding; what was confirmed is only that the keyboard interaction works on the path that
was reachable -- the npub dialog's field moved from a bottom edge of y=1250 to y=840 with
`mInputShown=true`, so ime handling is live on this build. The eight Scaffolds themselves
were not each opened with a keyboard up. `ChatRoomCreationScreen`, reached through New Chat
-> Start a group chat, is the shortest path for whoever checks.
**Tests.** 944 pass, 595 jvm over 72 classes and 349 android over 44, unchanged. Window
insets are a property of a running composition against a real window; there is no Compose
UI test infrastructure here to assert them, and a test that the modifier is present would
only restate the diff.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
9dc748f2d3