feat/tauri2-desktop-migration #120

Merged

nrupard merged 3 commits from feat/tauri2-desktop-migration into main

2026-05-15 22:33:11 +02:00

nrupard commented

2026-05-15 22:33:06 +02:00

Owner

No description provided.

nrupard added 3 commits

2026-05-15 22:33:06 +02:00

feat(desktop): migrate from Tao+Wry to Tauri 2 3daba48c30

Swap the desktop wrapper's webview shell from raw Tao+Wry to Tauri 2. The wrapper still loads `LETS_CHAT_SERVER_URL` in a system webview; this change is the foundation that unlocks the IPC bridge, the per-origin permission allow-list, native plugins (single-instance is wired now; tray, notifications, autostart land in follow-ups), the Tauri bundler, and the Android/iOS targets that became first-class in Tauri 2. The server crate is untouched.

Webview-string loading is no longer a built-in builder method as it was in Wry, so the "couldn't reach the configured server" welcome page is now served through a registered `welcome://` URI scheme handler instead of `WebViewBuilder::with_html`. The probe + render logic in `welcome::server_reachable` / `welcome::render` are kept as-is; only the delivery path changes.

`tauri-build` emits ACL/capability JSON under `desktop/gen/` at compile time; that path is gitignored. A `capabilities/default.json` grants `core:default` to the `main` window, matching today's "the page can do whatever the system webview lets it do" surface; tightening this is a follow-up. Bundling is disabled in `tauri.conf.json` so the migration does not yet produce `.dmg`/`.msi`/`.AppImage`/etc - those land alongside CI bundling work.

`desktop/icons/icon.png` is a 256-wide RGBA conversion of the repo's `lets-chat.png` to satisfy `tauri::generate_context!()`'s default-icon requirement.

Mobile (Android/iOS) targets, screen-share + permission hooks, OS-native notifications, system tray, the bundler-driven release artifacts, and the port of `desktop/src/update.rs` to `tauri-plugin-updater` are all out of scope for this PR and tracked as follow-ups.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

ci(desktop): wire Tauri 2 build files into the workflow paths and Windows cross-compile c5bd8b6e76

Three workflow-side adjustments needed after the Tauri 2 swap:

The build-desktop-{linux,windows} `paths:` filters previously fired only on `desktop/src/**` and `desktop/Cargo.toml`. The migration introduced four more inputs that change what the binary actually links: `desktop/build.rs` (which now invokes `tauri_build::build()`), `desktop/tauri.conf.json` (the source-of-truth config that `tauri::generate_context!()` reads at compile time), `desktop/capabilities/**` (the ACL surface that tauri-build folds into the binary), and `desktop/icons/**` (the default icon set required by `generate_context!()` and the Windows resource embedding step). Each is now part of the filter so an isolated change to any of them triggers a rebuild instead of silently shipping a stale binary.

The Windows cross-compile needs `desktop/icons/icon.ico` in addition to the `icon.png` Linux relies on. `tauri-build` runs `embed-resource` to bake a Windows resource into the PE binary on `x86_64-pc-windows-gnu`, and that step hard-requires a real .ico. Without it the cross-compile fails with `icons/icon.ico not found; required for generating a Windows Resource file during tauri-build`. The .ico committed here is a multi-resolution (16/32/48/64/128/256) RGBA conversion of `desktop/icons/icon.png`, generated via `magick icon.png -define icon:auto-resize=... icon.ico`.

Both Dockerfile comments updated to describe the Tauri 2 dependency surface (GTK 3 + WebKit2GTK 4.1 + libsoup 3 on Linux; mingw-w64 + windres + webview2-com on Windows) so future-me does not chase the wrong native deps.

Verified locally: `docker buildx build -f ci-build/Dockerfile.desktop-linux .` produces a 15 MB x86_64 ELF and `docker buildx build -f ci-build/Dockerfile.desktop-windows .` produces a 22 MB x86_64 PE32+. Both unchanged in shape from the pre-migration Tao+Wry artifacts; CI extraction paths (`/build/target/release/lets-chat-desktop` and `/build/target/x86_64-pc-windows-gnu/release/lets-chat-desktop.exe`) still resolve.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

fix(dev-desktop): mount XAUTHORITY and grant xhost so the Tauri 2 window can open the X display

Check / clippy + fmt + tests (pull_request) Successful in 2m52s

Details

26ee755f77

`just dev-desktop` was exiting with `Gtk-WARNING: cannot open display: :0` because the compose stack forwarded `DISPLAY` but never carried the X11 auth state into the container, so the X server rejected the connection before Tauri's GTK init could open a window. The wrapper script at `dev/cargo-desktop` had been doing this correctly for ad-hoc `cargo run`, so the gap was specific to the compose path.

Two-sided fix:

The `just dev-desktop` recipe now defaults `XAUTHORITY` to `$HOME/.Xauthority`, touches the file to make sure docker can bind-mount it (a bind mount of a missing host path silently turns into an empty directory that then masks the real cookie file forever), and runs `xhost +SI:localuser:$(id -un)` when an X server is available. The xhost grant is what unblocks GTK on the typical desktop setup; the cookie mount is the belt-and-braces path for environments where xhost is not installed.

`compose.dev-desktop.yml` now passes `XAUTHORITY` through, mounts the cookie file at the same path inside the container, and stops defaulting `DISPLAY` to `:0`. The `:0` default was actively harmful on Wayland-only sessions: the container would try X first, fail, and exit before GTK ever consulted `WAYLAND_DISPLAY`. With `DISPLAY: ${DISPLAY:-}` an unset host DISPLAY stays unset in the container and GTK falls straight through to the Wayland socket (which the existing `${XDG_RUNTIME_DIR}` mount already exposes).

The compose comment block is refreshed to mention Tauri 2 and to explain the recipe-and-compose split: compose has no `if` construct, so the auth-bootstrap work has to live in the justfile recipe and compose just consumes the resulting state.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>