Repository navigation
Really close the window to the tray on Linux - #3
Conversation
Wayland can't hide a window, so 'close to tray' only minimized it and Rig Hub stayed in the taskbar. On Linux the window is now destroyed; the App, workers and tray outlive it, the tray menu keeps refreshing, and 'Open Rig Hub' opens a fresh window on the same state. Windows and macOS keep minimizing: their tray needs the event loop. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
No actionable comments were generated in the recent review.
|
| Layer / File(s) | Summary |
|---|---|
Shared repaint context src/workers.rs, src/main.rs |
A cloneable workers::Context stores an egui context and requests repaints through it. App setup passes the shared context to workers and the tray. |
Linux tray and window lifecycle src/main.rs |
Linux attaches the retained app to each new egui context. It waits for a tray request after the window run ends, then can start another run. Non-Linux close-to-tray handling remains in the app logic. |
Priority:
Estimated code review effort: 3 (Moderate) | ~25 minutes
Change: Bug fix
Sequence Diagram(s)
sequenceDiagram
participant MainLoop
participant Eframe
participant Shell
participant App
participant Tray
MainLoop->>App: Attach to the new egui context
MainLoop->>Eframe: Start window run
Eframe->>Shell: Delegate app logic and UI
Shell->>App: Run app logic and UI
Eframe-->>MainLoop: Return when the window closes
MainLoop->>App: Wait in tray when close-to-tray is enabled
App->>Tray: Refresh status and wait for a show request
Tray-->>App: Deliver show request
MainLoop->>Eframe: Start a new window run
Merge Risk: 
Minimal · up to c4290
-
The Linux close-to-tray and reopen paths show no identified merge-blocking defect. Normal platform checks can proceed.
Security architecture risk: 
Low · up to c4290
-
The change remains within the desktop application and preserves the existing device-control authority. No introduced security violation was established. The main remaining uncertainty is platform-specific behavior when closing, reopening, or failing to recreate the window.
Retained concerns
No architecture-level concerns identified.Security review details
-
Security Blast Radius
- inferred — The demonstrated affected scope is the running desktop application and the local peripherals its existing workers control. The new window lifecycle does not itself grant additional device authority or provide activation clients with a device-command interface.
Security Findings and Attack Paths
- inferred — No introduced sensitive-command path was established from the inspected activation source: socket connections request Show only. Tray menu identifiers separately select opening the window, opening the existing bug-report URL, or quitting; the socket does not supply those identifiers.
Trust Boundaries and Controls
- observed — The Unix activation socket retains its existing runtime-directory location with a temporary-directory fallback. The inspected listener does not check peer identity before producing Show. That behavior predates this PR, and activation already remained available while the previous close-to-tray implementation kept the application minimized.
Resilience and Maintainability Implications
- inferred — Repaint rebinding is separate from authoritative device state and command ownership. A repaint racing window replacement may miss the departing renderer, but replacement does not reset shared device state or replay queued device commands through a new worker instance.
-
Pre-merge checks: 
4 · 
1
-
Failed checks: 1 warning Passed checks: 4 passedFull details: Docstring Coverage
-
Explanation
Docstring coverage is 28.57% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documentation-only edits and deletions within surviving functions are included; unchanged diff context and fully deleted functions are excluded. Analyzed 7 functions across 2 files.
Resolution
Write docstrings for the functions missing them to satisfy the coverage threshold.
-
Finishing Touches: 💡 1
-
📝 Generate docstrings: 💡
-
- Commit to this branch
- Create a new PR
🧪 Generate unit tests (beta)
-
- Commit to this branch
- Create a new PR
-
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Comment @coderabbitai help to get the list of available commands.
With "Keep running in the tray when closed" on, closing the window only minimized it, so Rig Hub stayed in the taskbar. On Wayland, winit can't hide a window (
set_visibleis unsupported), so minimizing was the fallback.On Linux the window is now destroyed on close:
App, its device workers and the tray outlive the window.main()rerunseframe::run_nativewhen the window is reopened, through a smallShellwrapper around a sharedApp.workers::Context, so their updates reach whichever window is open.Windows and macOS keep minimizing. Their tray needs the event loop running, so destroying the window there would freeze the tray.
Validation
cargo clippy --all-targets -- -D warnings: cleancargo test: pass (6 tests)🤖 Generated with Claude Code
Summary by CodeRabbit