schaefera/TouchPass
Watch
1
0
Fork
You've already forked TouchPass
 0
Code Issues 6 Pull requests Projects Releases 1 Packages Wiki Activity Actions

Scripted app flows: drive the full app on the desktop, like Playwright #17

New issue
Open
opened 2026-10-13 19:19:06 +00:00 by claude-bot · 1 comment
claude-bot commented 2026-10-13 19:19:06 +00:00
Collaborator

Why

UI changes currently get checked by hand on the phone or by single-page QML tests against fake stores. PR #16 is an example: its review left the wizard screens and the "busy syncing" / delete-failure paths to check by hand. A scripted way to click through whole flows against the real Rust backend would catch more before a device check and give PRs screenshots as proof.

Proposal

  1. cargo make flow-test: QtTest flows that load the real Main.qml with the real bridge, in clickable's amd64 image under Xvfb. That's the same setup as qml-test, so there are no new dependencies.
    • Each test gets a temp data dir and, where needed, a local bare git repo as origin (file URL, no SSH).
    • Steps use mouseClick/keyClick and findChild by objectName, and save grabImage screenshots as artifacts.
    • First flows:
      • new store, then add an entry, then copy
      • clone with key, then sync
      • clone without key, then Start over
      • clone of an empty repo, then choose a key, then sync
      • clone, then a sync holding the lock, then Start over says "busy"
  2. Later, optional: Spix (Qt Quick remote control) in debug builds only. An outside script (or Claude) could then click, type and screenshot the running app by object path, so flows could be explored interactively, not only through written tests.

Notes

  • clickable desktop already runs the app on the desktop for looking at it by hand; see the comment below for whether it works.
  • Out of reach on the desktop, so still needed on the device: clipboard (#8), content-hub import, AppArmor confinement.
  • Flows need stable objectNames on the buttons and fields they touch. Add them as part of this work.

Done when

  • cargo make flow-test runs the flows above, green, and writes screenshots.
  • The repo CLAUDE.md lists it under Commands and says UI PRs attach its screenshots.
  • It can't run in Forgejo CI yet, because the runner's dind has no clickable image. Decide whether to add it there or keep it local like qml-test.
## Why UI changes currently get checked by hand on the phone or by single-page QML tests against fake stores. PR #16 is an example: its review left the wizard screens and the "busy syncing" / delete-failure paths to check by hand. A scripted way to click through whole flows against the real Rust backend would catch more before a device check and give PRs screenshots as proof. ## Proposal 1. **`cargo make flow-test`**: QtTest flows that load the real `Main.qml` with the real bridge, in clickable's amd64 image under Xvfb. That's the same setup as `qml-test`, so there are no new dependencies. - Each test gets a temp data dir and, where needed, a local bare git repo as `origin` (file URL, no SSH). - Steps use `mouseClick`/`keyClick` and `findChild` by `objectName`, and save `grabImage` screenshots as artifacts. - First flows: - new store, then add an entry, then copy - clone with key, then sync - clone without key, then Start over - clone of an empty repo, then choose a key, then sync - clone, then a sync holding the lock, then Start over says "busy" 2. **Later, optional: Spix** (Qt Quick remote control) in debug builds only. An outside script (or Claude) could then click, type and screenshot the running app by object path, so flows could be explored interactively, not only through written tests. ## Notes - `clickable desktop` already runs the app on the desktop for looking at it by hand; see the comment below for whether it works. - Out of reach on the desktop, so still needed on the device: clipboard (#8), content-hub import, AppArmor confinement. - Flows need stable `objectName`s on the buttons and fields they touch. Add them as part of this work. ## Done when - `cargo make flow-test` runs the flows above, green, and writes screenshots. - The repo CLAUDE.md lists it under Commands and says UI PRs attach its screenshots. - It can't run in Forgejo CI yet, because the runner's dind has no clickable image. Decide whether to add it there or keep it local like `qml-test`.
claude-bot commented 2026-10-13 19:21:28 +00:00
Author
Collaborator

clickable desktop trial (2026-10-13, on the #16 branch)

It works, with one flag:

  • clickable desktop --arch amd64 builds fine (about 45 s for the Rust release build). The launch then stops with "System requirement not met", because clickable detects the NVIDIA GPU and wants nvidia-container-toolkit.
  • clickable desktop --arch amd64 --no-nvidia launches the app. It runs as an XWayland window on the Wayland session, even though clickable warns "xhost not detected". The Lomiri theme renders correctly, and the header (sync, settings, add), the search field and the empty-list text all draw.
  • The app's data lives in ~/.clickable/home/.local/share/touchpass.aps/ on the host, so you can reset it between runs by deleting that folder.
  • The wizard was clicked through by hand: generate a key, then create a store. It worked, writing keys/<fpr>.asc and store/.gpg-id and ending on the empty entry list.
  • The only log noise is XDG_RUNTIME_DIR not set, which is harmless.

For the flow-test task: use --no-nvidia (or set it in clickable.yaml / an env var) so a GPU on the host doesn't break the run.

## `clickable desktop` trial (2026-10-13, on the #16 branch) It works, with one flag: - `clickable desktop --arch amd64` builds fine (about 45 s for the Rust release build). The launch then stops with "System requirement not met", because clickable detects the NVIDIA GPU and wants `nvidia-container-toolkit`. - **`clickable desktop --arch amd64 --no-nvidia`** launches the app. It runs as an XWayland window on the Wayland session, even though clickable warns "xhost not detected". The Lomiri theme renders correctly, and the header (sync, settings, add), the search field and the empty-list text all draw. - The app's data lives in `~/.clickable/home/.local/share/touchpass.aps/` on the host, so you can reset it between runs by deleting that folder. - The wizard was clicked through by hand: generate a key, then create a store. It worked, writing `keys/<fpr>.asc` and `store/.gpg-id` and ending on the empty entry list. - The only log noise is `XDG_RUNTIME_DIR not set`, which is harmless. For the flow-test task: use `--no-nvidia` (or set it in clickable.yaml / an env var) so a GPU on the host doesn't break the run.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
release-0.1.0
about-dialog
maintainer-email
v0.1.0
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
schaefera/TouchPass#17
No description provided.