Loading page...Загружаем страницу...正在加载页面...
AtlasRepo

I built an open-source dictation app in Tauri and Rust. Here are 5 things that broke.

Description and use

Talvio now reliably runs offline, handles hotkey‑initiated windows without deadlocks, keeps floating overlays from stealing focus, isolates the speech engine to prevent crashes, and preserves user settings across restarts.

Problem

The author needed a cross‑app dictation tool that works offline and does not send audio to a server, but encountered several technical issues while building it.

Outcome

Talvio now reliably runs offline, handles hotkey‑initiated windows without deadlocks, keeps floating overlays from stealing focus, isolates the speech engine to prevent crashes, and preserves user settings across restarts.

Workflow

  • 1. Queue window creation, showing, and destruction on the main thread using run_on_main_thread.
  • 2. Mark all floating windows with platform‑specific no‑activate flags so they never steal focus.
  • 3. Spawn a separate worker process for the speech engine (--transcribe-worker) and communicate via a binary protocol with length prefixes.
  • 4. Handle worker crashes by marking the GPU unavailable and retrying with a CPU‑only worker (--cpu-only).
  • 5. Correct the settings persistence mechanism to avoid wiping on shutdown.

Evidence

My first version built the WebView window right there in the callback. It worked most of the time. Sometimes it deadlocked the event loop, and then everything was dead: no overlay, no dictation, windows you couldn't drag.

Source

If you call anything window-related from a shortcut handler, a tray handler or a background thread in Tauri, go through run_on_main_thread.

Source

When the engine ran inside the app, any of those took the whole app down, or left it sitting on "Transcribing…" forever.

Source

Now every call into the speech engine goes to a worker process: the same executable started with --transcribe-worker.

Source

  • Record date: 2026-10-27T03:11:45.872Z