irisandClaude Fable 5.1
d17040b601
I5's transcript screen now runs on-device against a real ai-server on iris-android-app's new transcript-screen feature (extends I2's shell rather than a third one), with real scrolling, real touch-drag panning and tap-by-name accessibility all confirmed by screenshot/log evidence. I4's own emulator-side check (tap-by-name on the tabs demo) closed the same session, so its box ticks [x] now. Still [~], not [x]: the render-time number RUST.md's recommendation wants for iris couldn't be produced this pass, for a precise and recorded reason rather than a vague one -- dumpsys gfxinfo cannot see a SurfaceView's own GPU-drawn frames at all (0 frames reported across a gesture loop that visibly scrolled), and a SurfaceFlinger --latency fallback gave no per-frame history either on this Android version. The Compose side of the same loop did produce a real number under identical conditions (8.96% janky, 99th percentile 150ms), so this is now a one-sided number rather than a missing one on both sides. Also found and recorded: the AVD's saved snapshot carries a GPU config across restarts, so switching between the documented Vulkan boot recipes needs a cold boot (clearing snapshots/) that the emu wrapper does not force -- cost three different-looking crashes before the pattern was the snapshot, not the code. DECISIONS.md's DEFERRED item is updated with the numbers Iris needs to weigh the iris-vs-Masonry call; the call itself stays hers. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
53 lines
3.2 KiB
Markdown
53 lines
3.2 KiB
Markdown
# Decisions taken for Iris to review
|
|
|
|
Short list of design choices made by the design agent without asking, so
|
|
they can be judged and reversed later. Detail lives in RUST.md (and IRIS.md
|
|
for iris API changes); this file is only the summary. Newest first. Items
|
|
marked **DEFERRED** are ones the agent chose not to decide alone.
|
|
|
|
## 2026-09-05
|
|
|
|
- **Touch drag on a transcript row follows Android's own rule**: a vertical
|
|
drag pans the list immediately; a stationary press held 500 ms starts a
|
|
text selection which further dragging extends; a horizontal drag while
|
|
something is already selected extends that selection without the wait.
|
|
One `DragArbiter` per list decides it (`iris/src/sense.rs`). Chosen over a
|
|
"text layer always wins" or "list always wins" rule because either loses
|
|
one of the two gestures a reader expects.
|
|
- **E4's desktop shape is a new `iris/desktop-app` crate**: a winit window
|
|
holding `transcript-ui`'s screen beside a session list, talking to a real
|
|
`ai-server` through `client-core`. It enrols by pasting the same
|
|
`aiapp://enroll?…` link a phone scans (`client-core::config::EnrolledServer`)
|
|
and keeps it owner-only under `$XDG_CONFIG_HOME/ai-app-desktop/`. The
|
|
pinned CA is a path given on the command line, not baked in. Chosen so
|
|
the phone and desktop share one enrolment format and no second one is
|
|
invented.
|
|
- **I5's Android integration extends `iris-android-app` (I2's shell)
|
|
behind a Cargo feature (`transcript-screen`), rather than a third
|
|
shell crate.** That project already has the Gradle module, the
|
|
`IrisView`/`MainActivity` Java, and the JNI registration; the only
|
|
thing a second screen needs on top is a different `AndroidAppState`,
|
|
the same axis `tabs_ui::build`/`transcript_ui::build` already vary
|
|
along on the winit side. `tabs-screen`/`transcript-screen` are
|
|
mutually exclusive and each pulls in only its own deps, so the plain
|
|
tabs build (I2/I4) is untouched.
|
|
- **Order of remaining work, updated 2026-09-05**: the two in-flight
|
|
pieces and I5's Android integration are all done; next is giving iris
|
|
its own frame-timing report so item 3 below can be decided by a number.
|
|
- **DEFERRED — whether to commit to iris over Masonry for `ai-app`.**
|
|
Updated 2026-09-05 with what's now known: iris's Android integration is
|
|
built and confirmed working on a real device (real server, real
|
|
scrolling, real touch-drag pan, tap-by-name accessibility — RUST.md's I5
|
|
box), while Masonry's own touch-scroll on Android was already found
|
|
entirely absent (E2). What's still missing on **both** sides is a
|
|
render-time number — not because iris doesn't work, but because
|
|
`dumpsys gfxinfo` cannot see a `SurfaceView`'s GPU-drawn frames at all,
|
|
so the `transcript-bench.sh`-style comparison this recommendation wanted
|
|
produced a real number for Compose (8.96% janky, 99th percentile 150ms,
|
|
same emulator/session) and none at all for iris. The choice in front of
|
|
Iris: decide now on the structural-plus-functional case already made
|
|
(iris works end-to-end where Masonry's scroll gesture doesn't exist at
|
|
all on Android), or wait for iris to grow its own frame-timing
|
|
instrumentation first so the comparison can be a number rather than a
|
|
qualitative one. RUST.md's "Recommendation" item 3 has the full account.
|