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>
29 lines
1.2 KiB
Rust
29 lines
1.2 KiB
Rust
//! I4 (RUST.md): the desktop half of the AccessKit push, over
|
|
//! `accesskit_winit`. `bench-lib.sh`'s tap-by-name goes through the
|
|
//! platform's real accessibility tree, so this crate only has to keep that
|
|
//! tree in sync with `ui::access::AccessTree`'s output -- nothing here
|
|
//! reacts to an AccessKit action request, which is why the three handlers
|
|
//! below are inert. See RUST.md's I4 box for why: on Android (and, by the
|
|
//! same platform convention, everywhere else) a screen reader's element tap
|
|
//! is a real touch delivered at the node's own bounds, not an action
|
|
//! request synthesised in-process -- so the ordinary pointer path already
|
|
//! handles it once the bounds are right.
|
|
use accesskit::{ActionHandler, ActionRequest, ActivationHandler, DeactivationHandler, TreeUpdate};
|
|
|
|
pub struct NullActivationHandler;
|
|
impl ActivationHandler for NullActivationHandler {
|
|
fn request_initial_tree(&mut self) -> Option<TreeUpdate> {
|
|
None
|
|
}
|
|
}
|
|
|
|
pub struct NullActionHandler;
|
|
impl ActionHandler for NullActionHandler {
|
|
fn do_action(&mut self, _request: ActionRequest) {}
|
|
}
|
|
|
|
pub struct NullDeactivationHandler;
|
|
impl DeactivationHandler for NullDeactivationHandler {
|
|
fn deactivate_accessibility(&mut self) {}
|
|
}
|