.forgejo/workflows/ci.yml

@@ -48,6 +48,19 @@ jobs:
       - name: Clippy (web crate, wasm client)
         run: cargo clippy -p feedsignal-web --no-default-features --features web --target wasm32-unknown-unknown -- -D warnings
 
+      # dioxus-desktop (tao/wry) needs GTK/WebKit headers to compile against
+      # on Linux; not baked into the rust-ci image since no other job needs
+      # them.
+      - name: Install desktop build dependencies
+        run: |
+          apt-get update
+          apt-get install -y --no-install-recommends \
+            libgtk-3-dev libwebkit2gtk-4.1-dev libsoup-3.0-dev \
+            libayatana-appindicator3-dev librsvg2-dev libxdo-dev
+
+      - name: Clippy (web crate, desktop)
+        run: cargo clippy -p feedsignal-web --no-default-features --features desktop --all-targets -- -D warnings
+
   test:
     needs: check
     runs-on: rust-ci

README.md

@@ -17,7 +17,10 @@ crates/
            chat completion for the relevance judgment on the shortlist.
   web/     axum + Dioxus fullstack UI. `server` feature = native binary
            (DB, feed polling, LLM calls, scheduler); `web` feature = the
-           WASM client shipped to the browser. No separate JS/npm stack.
+           WASM client shipped to the browser; `desktop` feature = a
+           self-contained native webview app that embeds the `server`
+           feature's DB/polling/LLM stack in the same process (no HTTP
+           hop, no separate server to run). No separate JS/npm stack.
 ```
 
 ### Two-stage relevance filtering
@@ -98,6 +101,22 @@ cd crates/web
 dx serve
 ```
 
+### Desktop
+
+`feedsignal-web`'s `desktop` feature builds a single native webview binary — DB, feed
+polling, LLM calls, and the scheduler all run in-process, so there's no separate server to
+start:
+
+```sh
+cd crates/web
+dx serve --platform desktop
+# or: cargo run -p feedsignal-web --no-default-features --features desktop
+```
+
+On Linux this needs GTK/WebKit dev headers (`libgtk-3-dev`, `libwebkit2gtk-4.1-dev`,
+`libsoup-3.0-dev`, `libayatana-appindicator3-dev`, `librsvg2-dev`, `libxdo-dev` on
+Debian/Ubuntu) — the same prerequisites as Tauri, since both build on `tao`/`wry`.
+
 The native crates (`core`, `db`, `feeds`, `llm`) build with plain `cargo check`/`cargo test` and
 don't need `dx` at all.
 

crates/web/Cargo.toml

@@ -43,3 +43,10 @@ server = [
     "dep:serde_json",
     "dep:tokio-cron-scheduler",
 ]
+# Self-contained native desktop build: a single binary with the webview UI
+# and the "server" feature's DB/feed-polling/LLM stack running in the same
+# process. `#[server]` functions dispatch on the "server" feature alone
+# (see dioxus-fullstack-macro), so enabling it here makes them execute
+# in-process instead of generating an HTTP client stub — no separate axum
+# server or network hop needed.
+desktop = ["dioxus/desktop", "server"]

crates/web/src/main.rs

@@ -8,5 +8,14 @@ fn main() {
     #[cfg(feature = "server")]
     server::init_tracing();
 
+    // `dioxus::launch`'s automatic platform detection prioritizes "server"
+    // over "desktop" when both features are enabled (as they are for the
+    // desktop build, which embeds the server feature for in-process
+    // `#[server]` calls) — it would stand up an axum server instead of a
+    // window. Pick the desktop renderer explicitly in that case.
+    #[cfg(feature = "desktop")]
+    dioxus::LaunchBuilder::desktop().launch(app::App);
+
+    #[cfg(not(feature = "desktop"))]
     dioxus::launch(app::App);
 }