bvandeusenandClaude Opus 5
42e06da576
The other half of #1899. Press the combination anywhere and a 520x220 window arrives over whatever you were doing; type, Ctrl/Cmd+Enter, it is gone. The board never comes forward, which is the whole point — bringing the app up to write one line is the friction this removes. ## There is no default shortcut, deliberately A global shortcut is the one setting here that can collide with software this app knows nothing about. Any default is a key combination taken away from something on somebody's machine, silently, at install time. So the feature is OFF until a combination is chosen, and choosing one is how it turns on. CommandOrControl+Shift+N is offered as a one-click suggestion, never applied on the user's behalf. ## Stored and live are reported separately `CaptureShortcut` carries both `shortcut` and `registered`, because they genuinely disagree: a combination another app grabbed first is saved and does nothing when pressed, and on Wayland a compositor may refuse global grabs outright. Saying only "your shortcut is X" would be a lie with a keystroke attached, so the settings row says "saved but isn't active — something else is holding it". `capture_shortcut_set` registers BEFORE storing, so a combination the system refuses is never written down as though it worked. Registration at startup is best-effort and logged: a shortcut that worked when it was chosen can be taken by something installed later, and the app must still open. ## Two windows, one database, no shared store The capture window runs a second copy of the frontend with its own Pinia stores, so a note saved there is invisible to the board until it is told. It is told — `capture_done(saved)` emits to `main`, and BoardView reloads. The emit failing is cosmetic (the note is already in SQLite) so it is logged, not raised. The window is opened at `index.html?capture=1` rather than at `/capture` because the bundled assets are served as FILES: a path with no file behind it 404s in the production build while routing fine under the dev server. The router turns the query into the route. It is hidden rather than closed on the way out, and it keeps its text. A capture interrupted by something more urgent is still there on the next press, which is what makes Escape safe to press. A failed save also keeps the window open holding the text — hiding it would throw away the only copy of something just written in order to report a problem you could retry your way out of. ## Where the setting lives Rule 25 says a tunable belongs in the UI, and this one has to be. It sits in the desktop's Sync screen beside the update channel, not in admin Settings: that screen is the SERVER's and bounces on desktop anyway, while this is a property of one installation on one machine. Persisted with the same `store::set_pref` the update channel uses. No @tauri-apps/api dependency was added — everything routes through `invoke` and the `withGlobalTauri` global, as the rest of the bridge does. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01K3MMqUtzX1TJgA1oypvm1c
ThoughtSync desktop (Tauri v2)
Local-first desktop client. The window loads the shared Vue 3 frontend from
../frontend; the Rust core (src-tauri) owns the on-device store and the opt-in
sync engine (built out across the M10 milestone). Works fully offline; optionally
syncs to a self-hosted ThoughtSync server.
Layout
desktop/
src-tauri/
Cargo.toml
build.rs
tauri.conf.json # frontendDist -> ../../frontend/dist, devUrl :5173
capabilities/default.json
src/
main.rs # thin shim -> lib::run()
lib.rs # tauri::Builder entry point
The Vue frontend is the sibling ../frontend package, shared with the web
build. On desktop it is backed by a local data source via
frontend/src/adapters/ (M10.3) instead of the server REST API. frontend and
src-tauri are siblings, not nested, so the beforeDev/beforeBuild
commands cd "$(git rev-parse --show-toplevel)/frontend" to resolve regardless of
the CLI's working directory.
Prerequisites
The toolchain (Rust + Node + WebKitGTK 4.1 + tauri-cli) is provided by the
ci-tauri CI image. For local dev: install Rust + Node, cargo install tauri-cli,
and the Tauri v2 Linux system deps — see CI-tauri/Dockerfile in the CI-runner
repo for the exact apt list (libwebkit2gtk-4.1-dev, libgtk-3-dev, librsvg2-dev,
libayatana-appindicator3-dev, libxdo-dev, patchelf, ...).
Dev
cd desktop/src-tauri && cargo tauri dev
beforeDevCommand starts the Vite dev server (port 5173) in ../frontend.
Build (Linux)
cargo tauri icon "$(git rev-parse --show-toplevel)/frontend/public/icon.svg"
cd desktop/src-tauri && cargo tauri build # -> .deb + .AppImage
App icons are generated from the frontend's icon.svg via cargo tauri icon
(not committed; CI does this before cargo tauri build). Bundle targets: deb,
appimage (Linux-first; Windows/macOS later, no code changes expected).
Status
Scaffold (M10.2): boots the shared Vue UI in a native window. Until the local data
adapter lands (M10.3 + M10.5) the app has no server configured, so it shows the
login screen without a working backend — full offline functionality arrives with
the local SQLite store (M10.4) + adapters/local.ts (M10.5).