Add compact Overview layouts - #2616
Conversation
clawsweeper
Bot
added
rating: 🧂 unranked krab
|
Codex review: needs maintainer review before merge. Reviewed August 12, 2026, 7:04 AM ET / 11:04 UTC. ClawSweeper reviewWhat this changesThis PR adds four persisted compact layouts for the merged Overview menu, with accessibility support, localization, documentation, and focused tests. Merge readinessKeep open for maintainer product approval and a rebase review: this is a coherent, proof-backed feature, but it adds a durable four-value user preference and GitHub reports the branch as dirty/non-mergeable. Likely related people: Peter Steinberger (medium-confidence current menu/settings history). Priority: P2 Review scores
Verification
How this fits togetherThe merged Overview menu turns enabled providers' usage models into interactive menu rows. The new preference selects how much provider and metric detail those rows display while preserving navigation to each provider. flowchart LR
A[Provider usage models] --> B[Merged Overview menu]
C[Overview layout preference] --> D[Layout selection]
B --> D
D --> E[Detailed or compact row projection]
E --> F[Interactive menu rows]
F --> G[Provider detail navigation]
Decision needed
Why: The implementation is coherent, but accepting a new durable settings contract and its UI complexity is a product choice rather than a mechanical correctness decision. Before merge
Agent review detailsSecurityNone. Review metrics
Merge-risk optionsMaintainer options:
Technical reviewBest possible solution: Adopt the feature only if maintainers want a permanent Overview-layout preference, then rebase it onto current main and revalidate the detailed default plus each reduced layout. Do we have a high-confidence way to reproduce the issue? Not applicable: this is a new UI capability rather than a report of broken behavior; the supplied screenshots directly show the proposed layouts and preference. Is this the best way to solve the issue? Unclear until product approval: the projection and migration are focused, but a durable four-choice preference should be accepted explicitly before it becomes supported behavior. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against a90dfed5c264. LabelsLabel justifications:
EvidenceWhat I checked:
Likely related people:
Rank-up movesOptional improvements that raise the rating; they are not merge blockers.
Rating scale
Overall follows the weaker of proof and patch quality. Workflow
HistoryReview history (7 earlier review cycles)
|
clawsweeper
Bot
added
the
merge-risk: 🚨 compatibility
clawsweeper
Bot
added
the
proof: sufficient
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c8fa050f48
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| guard metric.statusText == nil else { return nil } | ||
| return Lane( | ||
| id: metric.id, | ||
| title: UsageMenuCardView.popupMetricTitle(provider: model.provider, metric: metric), |
There was a problem hiding this comment.
When a Doubao account exposes both Coding Plan and Agent Plan windows, the plans share titles such as “5-hour”, “Weekly”, and “Monthly”; the detailed renderer explicitly separates them into plan-family groups in UsageMenuCardUsageContentView. Flattening every metric to popupMetricTitle here therefore produces duplicate, indistinguishable labels in the compact layout and in all reduced-layout VoiceOver summaries, so users cannot determine which plan a bar represents. Include the Doubao plan family in the projected title or otherwise preserve that grouping.
Useful? React with 👍 / 👎.
clawsweeper
Bot
added
proof: 📸 screenshot
81f1ed2 to
1c42622
Compare
1 participant
Summary
Why
Overview can become very tall when several providers expose multiple usage windows. These layouts let people choose how much detail the combined Overview displays without changing the existing detailed provider views.
Validation
make checkmake test— 812 selections across 68 groups passed with zero failures, retries, or timeoutsswift test --filter CompactOverview— 29 tests passed on the final branchswift test --filter ProviderArchitectureGatekeeperTests— 4 tests passed on the final branchScreenshots
Overview layouts
Preference