Load and save Wi-Fi networks in networks.toml (0600) instead of writing
PSKs back into breadcrumbs.toml. The password field is write-only.
Replace the generic argv runner with typed bakery/pacman/fwupd commands
and set a real Tauri CSP. Add Lock, Screenshots, Monitors, and Help
panels. Pin bread-theme and bread-utils to bread-ecosystem v0.7.1.
bread-screenshots is not on that tag, so --screenshot calls grim
locally. bakery.toml lists webkitgtk-4.1 deps; README/CLAUDE.md match
Tauri 2 + Svelte 5 and single-trunk main.
First bread-ecosystem app on the Tauri/webview stack rather than raw
GTK4 — proves the isolated-headless-Sway capture pipeline works against
a plain (non-layer-shell) tao/wry window with no gtk4-rs-specific signal
to hook. No connect_map here: since the window isn't owned by gtk4-rs
directly, this instead waits a fixed settle delay (2s — longer than the
native apps need, since a webview's first paint means a full page load
plus an async Tauri-command round-trip for real content, not just GTK
widget layout — confirmed by an initial 800ms attempt capturing the
sidebar correctly but the About panel's data still blank) on Tauri's own
async runtime, then captures the known-size canvas and exits.
Only one view ("default", the initial landing section) is wired up.
Capturing a specific sidebar section would mean routing the Svelte
frontend to a URL/hash on window creation — real, separate frontend
work, deferred past this first pass.
bread-screenshots is pulled from bread-ecosystem's dev branch, unlike
this repo's existing bread-theme/bread-utils deps which point at main —
it doesn't exist on main yet.
The path dependency on ../../bread-ecosystem/bread-theme (and bread-utils)
assumed a sibling checkout that doesn't exist on the CI runner — this was
the actual cause of release.yml never having succeeded, on top of the
Tauri build-path issue fixed separately. Switched to a git dependency
pinned to branch = "main" rather than a tag, since the functions this
migration needs (css_custom_properties/css_tokens) aren't in a tagged
bread-theme release yet. Verified with a full local build.
cargo build --release alone doesn't produce a working standalone binary in
Tauri v2 — embedding the frontend vs. hitting devUrl at runtime is gated by
the tauri/custom-protocol Cargo feature, not the debug/release profile.
The scaffold never declared it, so even release builds tried to connect to
localhost:1420. Added the standard default-on custom-protocol feature
(cargo tauri dev strips it via --no-default-features for dev builds); a
plain `cargo build --release --locked` in src/ now produces a real
standalone binary with no dev-server dependency.
Also fixes vite.config.js's file-watch ignore pattern, left stale by the
src-tauri -> src rename: a bare "**/src/**" glob would have also matched
frontend/src itself, so it's now an absolute path scoped to the Rust
project dir specifically.
