Replace the local web dashboard with a native GTK4 OpenFrag app

[NtrpyDev]

Goal

Replace the local browser dashboard with an installed native GTK4 desktop client before v1. Keep the daemon and recorder as background processes so capture and Game State Integration continue when the window is closed.

Settled architecture

One OpenFrag installation ships:

• openfrag, the GTK4 desktop client for stats, setup, Doctor, Match evidence, Clip review, settings, and status.
• openfragd, the private background service that owns SQLite, files, capture coordination, Game State Integration, imports, and mutations.
• openfrag-recorder, the pinned supervised capture helper.

The desktop client communicates with the daemon through a private Unix domain socket. It never opens SQLite directly. Remove the browser launcher, embedded dashboard HTML, loopback TCP listener, and public HTTP-shaped product language.

Five-round decision: GTK4 versus Tauri

1. Product fit: GTK4 wins because the requested product is genuinely native; Tauri remains a webview.
2. Existing UI reuse: Tauri wins because it could reuse HTML, CSS, and JavaScript.
3. Linux integration and accessibility: GTK4 wins through native widgets and desktop integration.
4. Security boundary: GTK4 wins because it removes the browser renderer and localhost transport from the trusted UI path.
5. Packaging and long-term ownership: GTK4 wins because OpenFrag is Linux-first and Rust-based, while Tauri adds a frontend toolchain plus a system webview dependency.

Winner: GTK4, four rounds to one. The short-term rewrite cost is accepted to avoid shipping a v1 interface already marked for replacement.

Required implementation

1. Add a Rust GTK4 desktop binary with canonical application identity and one main window.
2. Preserve domain logic below the UI. Expose typed daemon operations over a private, permission-restricted Unix socket.
3. Implement setup, Doctor, Match and Rating evidence, stats, Clip preview/review/trim/export, Manual Flag status, capture status, errors, and empty/loading states.
4. Keep capture and Game State Integration alive when the window closes. The app may activate or focus an existing window without starting a second daemon.
5. Remove the embedded HTML dashboard, JavaScript, browser launch path, localhost API listener, and their packaging/runtime dependencies.
6. Make every state keyboard accessible, screen-reader legible, deterministic under test, and safe with untrusted file names and imported content.
7. Package the client, daemon, service, launcher, icons, desktop metadata, and recorder as one product in AUR, Fedora 43, and Fedora 44 channels. The removed generic binary tar channel is not a v1 target.
8. Add focused widget/presenter tests, typed transport contract tests, accessibility-tree assertions, headless native journeys, and installed desktop smoke checks.
9. Update the support matrix with real KDE Wayland and GNOME Wayland results.

Acceptance criteria

• Launching OpenFrag opens a native desktop window, not a browser.
• No shipped process listens on TCP for the UI.
• Closing the window does not stop an enabled replay buffer or Game State Integration.
• The client cannot mutate SQLite or media outside the daemon contract.
• Every dashboard capability represented in v1 has an equal or stronger native workflow and automated proof.
• Installed AUR, Fedora 43, and Fedora 44 packages contain and launch the same application identity.
• PC1 and PC2 complete the native installed journey with explicit human observation.

[NtrpyDev]

User-authored placeholder assets supplied on 2026-07-15:

• Icon: /home/glorg/Pictures/openfrag-icons/openfrag_icon.png, 512 x 512 RGBA, SHA-256 660579ff55d5f5a7cf2e84411fd45a544926210f2454fd9ff598249849779200
• Banner: /home/glorg/Pictures/openfrag-icons/openfrag_banner.png, 1500 x 500 RGBA, SHA-256 652be5d4f5d480fa64f54035d22a5061422d526d34c88e86ddf1a50b327bef1f

Preserve the originals and import their exact bytes for the native app and documentation. Any later redesign is a separate explicit decision. Do not silently overwrite or regenerate these files.

[NtrpyDev]

Five-round transport decision: bounded JSON frames vs binary frames

The settled seam is one typed request and one typed response per private Unix-socket connection. Demo import passes an explicitly selected local path, and Clip preview returns a daemon-authorized path, so the transport does not need to carry large media payloads.

1. Inspectability: bounded JSON wins because a local request can be audited without a protocol-specific decoder.
2. Type safety: tie because both options use the same versioned Rust request and response enums.
3. Framing safety: binary length prefixes are slightly simpler for arbitrary bytes, but bounded newline-delimited JSON is safe here because strings escape newlines and media bytes never cross this seam. Winner: bounded JSON.
4. Performance: binary frames win on encoding size and CPU, though the expected control payloads are small.
5. Compatibility and diagnosis: bounded JSON wins because protocol mismatches and diagnostics remain human-readable across package versions.

Winner: bounded JSON, four rounds to one.

The implementation will cap request and response frames, reject trailing or unknown data, create the runtime directory with private permissions, create the socket with mode 0600, verify the peer user, and handle one request per connection. The small external interface is Client::execute(Request) -> Reply; storage, imports, capture, and setup remain behind the daemon adapter.

[NtrpyDev]

Native vertical-slice progress:

• Renamed the home surface from Tonight to Last Session in f7a566b.
• Added typed clip summaries to the private Unix-socket protocol in 07f1689.
• The daemon maps persisted clip records without exposing private media paths.
• The GTK Clips page now renders empty and populated review-list states.
• Verified cargo test -p openfrag --lib, cargo test -p openfrag-ipc, cargo test -p openfragd --test ipc_contract, and targeted Clippy with warnings denied.
• Live native window was launched against a composed daemon and rendered the real setup state and placeholder banner.

Ticket remains claimed. Clip editing, preview, trim, export, setup actions, diagnostics, match detail, Receipts, packaging, and native journey tests still remain before resolution.

[NtrpyDev]

Five-round setup mutation decision: broad form versus action enum

The native client must invoke setup mutations without letting invalid field combinations become routine protocol states.

1. Invalid-state prevention: the action enum wins because each variant carries only the fields that action accepts.
2. Reuse of the existing daemon DTO: the broad form wins because it can be forwarded with almost no translation.
3. Native UI dispatch: the action enum wins because each button constructs one explicit command instead of a string plus unrelated optional fields.
4. Protocol evolution: the action enum wins because adding or changing an action forces exhaustive compiler errors in the client and daemon adapters.
5. Security review and auditability: the action enum wins because consent, paths, and background preference are visible on the exact variants that use them.

Winner: a dedicated setup action enum, four rounds to one. The daemon adapter will translate it into the existing internal setup request so domain logic remains unchanged.

[NtrpyDev]

Native Doctor progress:

• e6eb4a2 exposes the daemon setup snapshot and renders every check and action in the GTK Doctor.
• A five-round comparison selected a dedicated setup mutation enum over a broad optional-field form, four rounds to one.
• 35b7b9f types every setup mutation and proves a real defer-GSI state change through daemon composition.
• fd1a6b9 wires GTK controls, required-field validation, explicit consent confirmation, asynchronous socket I/O, and full Doctor rerendering.
• A freshly linked target/debug/openfrag showed Last Session and reached Setup and Compatibility Doctor entirely by keyboard.
• The live defer action changed the rendered GSI state to Not tested / deferred.
• Closing the client window terminated the client while the same openfragd process remained alive.

Ticket remains claimed. Match details and Receipts, complete Clip workflows, import, Manual Flag, accessibility-tree automation, dashboard removal, and packaging remain.

[NtrpyDev]

Five-round Match navigation decision: inline expansion versus dedicated evidence page

1. Scanability: inline expansion wins because the user can peek without leaving the Match list.
2. Information capacity: a dedicated page wins because player stats, Rating state, and many Receipts need stable space.
3. Keyboard and screen-reader navigation: a dedicated page wins because it has one heading and predictable controls instead of changing row geometry.
4. Receipt drill-down: a dedicated page wins because it can open evidence without nesting interactive controls inside a list row.
5. Future growth: a dedicated page wins because round timelines and comparisons can grow without destabilizing the Match list.

Winner: a dedicated Match evidence page, four rounds to one. The Match list remains a fast, single-action index, and selecting a row opens the evidence page inside the same native window.

[NtrpyDev]

Five-round Demo picker decision: FileChooserNative versus FileDialog

1. Async GTK integration: FileDialog wins because its API is future-based and fits the nonblocking client workflow directly.
2. Old GTK compatibility: FileChooserNative wins because it exists before GTK 4.10.
3. Desktop portals: tie because both can delegate to the platform file chooser under supported desktops.
4. API longevity: FileDialog wins because FileChooserNative is deprecated in current GTK.
5. Supported v1 packages: FileDialog wins because Fedora 43, Fedora 44, and current Arch all satisfy GTK 4.10 or newer, so the older floor does not benefit a claimed v1 channel.

Winner: FileDialog, three rounds to one with one tie. OpenFrag will raise its declared GTK feature floor to 4.10 and pass only the explicitly selected local Demo path to the private daemon.

[NtrpyDev]

Native evidence and import progress:

• A five-round navigation comparison selected a dedicated Match evidence page over inline row expansion, four rounds to one.
• 07710a6 adds typed Match detail and Receipt requests, dedicated GTK pages, loading states, back navigation, bounded imported evidence text, and typed not-found errors.
• A five-round picker comparison selected GTK FileDialog over FileChooserNative, three rounds to one with one tie.
• 963c9d2 raises the supported GTK floor to 4.10, opens a filtered native Demo picker, passes only the selected absolute path, rejects relative paths, non-Demo files, non-regular files, symlinks, and files over 2 GiB, and refreshes Matches after a completed import.
• Demo reading and parsing run on blocking worker pools so neither the GTK event loop nor the daemon async socket executor is blocked.
• Presenter, private protocol, real daemon composition, former API compatibility, targeted Clippy, and linked native binary checks pass.

Ticket remains claimed. Clip preview and mutations, Manual Flag and diagnostics, browser-surface removal, accessibility automation, and native packaging still remain.

[NtrpyDev]

Five-round Manual Flag placement decision: Setup versus Last Session

1. Setup clarity: Setup wins because portal approval and initial shortcut availability are configuration concerns.
2. In-match reachability: Last Session wins because Manual Flag is a routine capture action after setup, not a configuration task.
3. Status visibility: Last Session wins because capture, Game State Integration, and shortcut readiness belong beside current operating status.
4. Error recovery: Last Session wins because a failed flag can show an immediate local error without sending the user back into setup.
5. Accessibility and workflow separation: Last Session wins because configuration stays in Doctor while the primary operational action remains in the main tab order.

Winner: Last Session, four rounds to one. Setup retains approval and repair actions; Last Session gains typed diagnostics, current capture status, and the Manual Flag action with a deterministic result or explicit error.