irisandClaude Opus 5
a9312e9431
Iris: "the organization of the rust rewrite is a mess right now... there shouldn't be anything related to the app inside of iris. Iris is supposed to be the UI framework alone." And, on the crate count: "I'm confused why the app only code needs more than one crate though." Nine cargo workspaces become three, and the port's project code -- which sat in five places, four of them inside the framework -- becomes one crate, `ai-app`, in `app-rust/`: client-core -> app-rust/src/client iris/transcript-ui -> app-rust/src/ui iris/transcript-fixture -> app-rust/src/ui/fixture.rs + tests/ + touch/ iris/desktop-app -> app-rust/src/desktop + src/bin_desktop.rs iris/android-app -> app-rust/src/android + android-project/ android-shell -> app-rust/src/shell iris/ keeps core, macro, the iris crate, tabs-ui and rig-input, and now mentions no session, transcript, setup or server anywhere. Only two of the old splits had a reason that survived reading. event-model stays a crate at the repo root because server/ depends on it too, so a crate is what makes the backend and the app agree by construction. The two Android .so names looked like a hard constraint -- a package produces one library artifact -- until P2 turned out to already plan merging those two Android apps into one; both faces now come out of libai_app.so, picked apart by features so `--no-default-features --features shell` keeps wgpu, parley and iris out of the Compose app's APK. docs/RUST.md's "One app crate" has the rest, including what each remaining feature is for. DECISIONS.md and SUBAGENTS.md move into docs/ with everything else. Verified: ./run-tests.sh and `cd iris && cargo test` green, clippy and fmt clean in all five workspaces, `cargo ndk -t x86_64` links libai_app.so, build-apk.sh produces an APK that installs and launches on this checkout's emulator (Gl ... virgl, as expected), and the phone-sized headless screenshot renders the transcript unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
33 lines
1.3 KiB
TOML
33 lines
1.3 KiB
TOML
[package]
|
|
name = "rig-input"
|
|
version.workspace = true
|
|
edition.workspace = true
|
|
|
|
# Layer 2's input half (docs/RUST.md's "Three test layers"): replays one
|
|
# of the `.touch` files the headless tests use into whatever window is
|
|
# under a Wayland compositor, so the *same recording* drives the
|
|
# assertion layer and the layer a person looks at.
|
|
#
|
|
# It exists because this machine's compositor has no pointer to move.
|
|
# `run-headless.sh` starts sway on the headless backend with no input
|
|
# devices at all (`WLR_LIBINPUT_NO_DEVICES=1`, `LIBSEAT_BACKEND=noop`),
|
|
# so `swaymsg seat - cursor press` reports success and nothing reaches
|
|
# the client -- `swaymsg -t get_seats` shows `capabilities: 0`. wlroots
|
|
# 0.19 dropped `WLR_HEADLESS_INPUTS`, and ydotool's uinput device would
|
|
# be ignored by a compositor that is not reading libinput. The
|
|
# virtual-pointer protocol is what is left, and it is a client protocol,
|
|
# so it needs no devices and no root.
|
|
|
|
# Named for what it does rather than for the crate, since the crate may
|
|
# grow a keyboard replay beside it.
|
|
[[bin]]
|
|
name = "replay-touch"
|
|
path = "src/main.rs"
|
|
|
|
[dependencies]
|
|
# `TouchScript` -- the same parser the harness uses, so a file that
|
|
# replays here and one that replays headless can never disagree.
|
|
iris = { path = ".." }
|
|
wayland-client = "0.31.15"
|
|
wayland-protocols-wlr = { version = "0.3.12", features = ["client"] }
|