Bring Linux desktop primary UI closer to the macOS menu design

[stackingrockss]

Problem

The first-party Linux desktop is useful, but its primary presentation feels like a generic Qt dashboard rather than the compact CodexBar experience on macOS. On Linux, Dashboard.qml opens an 820×700 Usage & Spend window with stacked provider Frame cards, default Qt controls, and a separate Spending tab. The macOS menu instead has a provider/Overview switcher, one focused provider at a time, a clear provider/update/plan header, compact usage bars with reset and pace text, inline credits/cost, and lightweight footer actions.

This is especially noticeable on Pop!_OS/COSMIC, where the Linux frontend uses Qt's Fusion style and system palette rather than Omarchy's optional theme integration. The goal is visual and interaction parity for the primary Linux usage surface, not a change to provider fetching or authentication.

References: Mac menu screenshot, current Linux dashboard, Linux/Mac comparison.

Proposed design

• Make a compact Quick View the default usage window. Include Overview and provider switching with the existing provider SVG icons, selected-state accent, and compact quota indicators.
• Match the Mac menu's information hierarchy within each provider: identity/plan and last update; usage windows, reset times, and pace; credits/cost where available; then actions.
• Replace generic control styling in that surface with shared semantic light/dark tokens, compact spacing, dividers, and thin progress tracks while preserving accessibility and legible contrast.
• Keep the full Usage & Spend dashboard available for charts and detailed history instead of discarding those Linux features.
• Bring Linux Settings closer to the Mac sidebar structure as a follow-up or separately reviewable slice, retaining Linux-only controls.

Boundaries

This should reuse the existing Qt desktop and Swift CLI data contract. No new dependency, provider/auth change, local-data migration, or macOS behavior change is intended. A Wayland/COSMIC window cannot be promised the exact menu-bar anchoring behavior of an AppKit status-item popover; parity here means the content, hierarchy, and visual language inside the window.

Acceptance criteria

• Quick View is the default usage entry point; full dashboard and Settings remain reachable.
• One-provider and multi-provider states, Overview, refresh/loading/stale/error/empty states, long labels, and hidden account identity render without clipping.
• Light and dark appearances plus common display scales are visually checked against equivalent synthetic Mac reference data; screenshots accompany the PR.
• Keyboard navigation and accessible names remain usable; existing CLI fetching, spending, tray, startup, and settings behavior is preserved.

[clawsweeper]

Codex review: this still needs some work. Reviewed September 24, 2026, 9:13 PM ET / September 25, 2026, 01:13 UTC.

Summary
The requested compact Linux view is still absent from current main. The proposal fits the repository’s Linux desktop exception, but making it the default is a product choice that needs owner sign-off.

Reproducibility: not applicable. this is a UI feature request. The current window layout and routing are directly visible in the QML source.

Maintainer decision needed

Question	Recommendation
Should the Linux Qt desktop open a compact provider-focused Quick View by default while retaining the current Usage & Spend dashboard as a secondary view?	Sponsor a focused Quick View: Approve the compact default as a first slice and review Settings parity separately.

Why: This changes the primary Linux interaction and expands the maintained UI surface; VISION.md requires sign-off for new features and broader changes.

Next step
The owner needs to approve the compact default and scope before implementation; the existing Linux desktop is working as documented.

Review details

Best possible solution:

Approve a bounded Qt Quick View design that reuses the existing CLI data, preserves the detailed dashboard, and validates keyboard access plus light and dark layouts with synthetic provider states.

Do we have a high-confidence way to reproduce the issue?

Not applicable: this is a UI feature request. The current window layout and routing are directly visible in the QML source.

Is this the best way to solve the issue?

Unclear until the owner approves the default interaction. A focused Quick View that reuses the existing data path and retains the detailed dashboard is a maintainable direction.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning medium; reviewed against b305668fc5cc.

Label changes

Label changes:

• add P3: This is a proposed presentation improvement; the existing Linux usage and spending views remain functional.
• add issue-rating: 🌊 off-meta tidepool: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.
• add clawsweeper:needs-product-decision: Current issue advisory state selects this label.

Label justifications:

• P3: This is a proposed presentation improvement; the existing Linux usage and spending views remain functional.

Evidence reviewed

What I checked:

• Current Linux entry point: The Linux window is still titled Usage & Spend, sized 820 by 700, and switches between Usage and Spending tabs. (Integrations/Linux/qml/Dashboard.qml:8, b305668fc5cc)
• Current window routing: Usage and spending requests both open the existing dashboard; there is no separate Quick View route. (Integrations/Linux/qml/Main.qml:10, b305668fc5cc)
• Existing Linux contract: The Linux guide describes the current usage window, separate spending view, and the CLI-backed adapter interface. (Integrations/Linux/README.md:188, b305668fc5cc)
• Product scope: VISION.md explicitly includes the Linux Qt desktop as an exception to the community-integration boundary and calls for sign-off on new features and broad UI changes. (VISION.md:1, b305668fc5cc)
• Feature history: Linux dashboard and settings history identifies Peter Steinberger's original desktop and subsequent UI work; merged pull requests Add portable Linux desktop with separate windows and shared Omarchy backend #3573 and Add Linux provider ordering, tray meters, account actions and display settings #3575 established the current surface. (Integrations/Linux/qml/Dashboard.qml:8, 213093a73903)
• Release comparison: The latest release tag v0.66.0 also contains the 820 by 700 Usage & Spend window, so the requested default view is absent in both that release and current main. (Integrations/Linux/qml/Dashboard.qml:8, e665cbf64976)

Likely related people:

• steipete: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[steipete]

The Linux desktop introduced in 0.60.0 already has usage/spending views, quota bars, reset formats, pace, account selection, notifications, and tray meters. Its primary UI still opens a regular Usage & Spend window from the tray; it does not yet provide the compact anchored menu, Overview/provider switcher, or in-popup drill-in of the macOS app.

A useful first slice would be an optional compact popup reusing the existing backend and cards, while retaining the normal window as a fallback. Provider navigation and compact/detail controls can follow separately. Saved-account editing and managed-account promotion are separate functionality, not styling changes. The broader interface-parity request remains open.

[steipete]

Pointer: #3973 now proposes a compact Quick View window. It changes the default interaction rather than adding the optional popup recommended above, so it is waiting on the same default-window decision; the opt-in shape is described on that PR.