Skip to content

dokime-gui

Responsibility: the Tauri 2 desktop shell and React operator application.

The binary owns the desktop session. native_session selects and supervises the backend, connection holds the gRPC client and its credentials, rpc bridges typed IPC to that client, and app creates the configured windows, exposes safe open-path/open-target/title commands, and provides private GitLab sign-in and updater commands. The shell links no runtime of its own.

app::logging::init installs the shell’s own tracing subscriber before tauri::Builder runs, so a stall in the bridge (rpc/mod.rs, rpc/client_streams.rs) is diagnosable even when it happens before the webview reaches a single command. RUST_LOG sets verbosity (default info) for two copies of the stream: stderr, and a non-blocking daily-rolling file under the platform’s app log directory, named dokime-gui.<date>.log:

  • Linux: $XDG_DATA_HOME/com.stokker.dokime/logs (typically ~/.local/share/com.stokker.dokime/logs).
  • macOS: ~/Library/Logs/com.stokker.dokime.
  • Windows: %LOCALAPPDATA%\com.stokker.dokime\logs.

The shell logs the resolved file path once at startup, at info. This is a separate stream from the backend’s own dokime-serve.<date>.log (see the dokime-cli reference) — a plugin stage that never reaches the backend still leaves a trail in the shell’s log.

A session is owned, parent-owned, or remote. An owned session runs the dokime executable the installer places beside the application: the shell finds it, confirms that its version and development protocol match, starts dokime serve with the configured execution folder and plugin store, attaches to the loopback endpoint the backend publishes, and stops it by closing its control pipe and waiting for it to drain. --endpoint attaches to a backend another process started — cargo dokime dev launches the shell this way — and that backend keeps running when the desktop closes.

Discovery looks beside the application first, then at DOKIME_HOME, PATH, and the platform install directories. Starting a local backend is offered only when a bundled dokime is found; otherwise the control is disabled and names the installer.

The frontend is organized around workflow views (Plan, Execution, Cycle), Explore history/comparison, and Settings. Feature modules call the backend’s native gRPC services through the session and generated protobuf contracts; the runtime remains the state authority.

Tauri configuration targets Windows NSIS and Linux DEB/RPM installers. It bundles the desktop application, embedded frontend, branding, and the dokime CLI as its external binary, with signed updater artifacts when signing credentials are supplied. The two executables install side by side, and on Windows the installer adds that directory to the user PATH. Plugins install separately, through the plugin store or an explicit bundle path.

Dokime markDokime · Stokker Technologies