Color-coded menu bar icons + separator style + time-window selection (macOS 26 aware)#1207
Color-coded menu bar icons + separator style + time-window selection (macOS 26 aware)#1207johnlarkin1 wants to merge 5 commits into
Conversation
…Gen crash) The nested makeTitle() in AccountSwitcherView.compactButtonTitle captured the mutable emailWidth/workspaceWidth vars, which crashes swift-frontend (IRGen, SIGABRT) under the Swift 6.2.3 + macOS 26.4 SDK toolchain. Pass the widths as parameters so the nested function captures only immutable values. No behavior change. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
Color-coded icons (Advanced ▸ "Color-coded icons", default on): - UsageColorLevel.tintColor(for:) interpolates green→orange→red by session usage, applied in both StatusItemController icon paths. - IconRenderer.makeIcon(tintColor:) draws shapes directly in the tint color and marks the image non-template so macOS 26 Liquid Glass keeps the RGB pixels; older macOS still tints the template via the button's contentTintColor. Tint participates in the icon cache key and the render-skip signatures. - StatusItemController observes effectiveAppearance on macOS 26+ to re-render baked colors on dark/light switches. Separator style (Display ▸ "Separator", dot/pipe, default dot): - MenuBarSeparatorStyle drives the character between percent and pace in the "both" menu-bar display mode. Adds colorCodedIcons + menuBarSeparatorStyle settings plumbing and tests. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
|
Codex review: needs real behavior proof before merge. Reviewed May 30, 2026, 10:17 AM ET / 14:17 UTC. Summary Reproducibility: yes. for the review findings through source inspection: absent colorCodedIcons resolves to true, and ProviderBrandIcon.image returns template images while brand-percent applies contentTintColor. I did not run the macOS UI because this is a read-only review. Review metrics: 3 noteworthy metrics.
Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Proof guidance:
Mantis proof suggestion Risk before merge
Maintainer options:
Next step before merge
Security Review findings
Review detailsBest possible solution: Keep the feature behind upgrade-compatible defaults, render every advertised color-coded menu-bar path with macOS 26-safe non-template images, and require updated visual proof for the time-window controls before merge. Do we have a high-confidence way to reproduce the issue? Yes for the review findings through source inspection: absent colorCodedIcons resolves to true, and ProviderBrandIcon.image returns template images while brand-percent applies contentTintColor. I did not run the macOS UI because this is a read-only review. Is this the best way to solve the issue? No: the feature direction is useful, but the merge path should preserve upgrade appearance, use baked non-template tinting for brand-percent mode on macOS 26, and add current-head proof for the time-window controls. Full review comments:
Overall correctness: patch is incorrect AGENTS.md: found and applied where relevant. Codex review notes: model gpt-5.5, reasoning high; reviewed against 72716d9fd545. Label changesLabel changes:
Label justifications:
Evidence reviewedWhat I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 449026a333
ℹ️ 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".
| // appearance changes so dynamic colors (systemGreen/Orange/Red) resolve to their new values. | ||
| if #available(macOS 26, *) { | ||
| self.appearanceObservation = NSApp.observe(\.effectiveAppearance) { [weak self] _, _ in | ||
| Task { @MainActor in self?.updateIcons() } |
There was a problem hiding this comment.
Invalidate icon render signatures on appearance changes
When the macOS 26 appearance observer fires, calling updateIcons() is not enough to re-render the baked non-template tint: if usage/status values are unchanged, applyIcon rebuilds the same tint= signature and shouldSkipMergedIconRender/shouldSkipProviderIconRender returns before IconRenderer.makeIcon can resolve the dynamic system color again. In the dark/light switch case described in the comment, the old RGB bitmap can therefore remain until some other icon-signature input changes; clear the cached render signatures or include an appearance/color hash in them before updating.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
this is also fixed
Addresses two review findings: - Observe menuBarSeparatorStyle in the menu observation token, so changing the Dot/Pipe picker refreshes the status item immediately instead of waiting for another observed setting or usage update. - On the macOS 26 effectiveAppearance change, clear the cached icon render signatures before updateIcons(). The signatures don't encode appearance, so an unchanged usage/status value would otherwise short-circuit the re-render and leave the stale baked (non-template) bitmap until some other input changed. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The toggle lived under Advanced, making it hard to find next to the other menu-bar appearance settings. Move it into Display ▸ Menu Bar (default stays on) so the disable option sits where users look for menu-bar icon options. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
@clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
Adds a third menu-bar configuration: independent session vs weekly time-window selection for the percent and pace values. - MenuBarTimeWindow enum (session/weekly) - Two persisted settings with backward-compatible defaults (percent=session, pace=weekly) - Segmented pickers in the Display preferences pane, gated on display mode - StatusItemController selects the percent/pace window per setting (session -> menuBarPercentWindow / UsagePaceText.sessionPace, weekly -> secondary / UsageStore.weeklyPace) - Round-trip test for the new settings Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
Thanks for exploring these menu-bar options. Closing this combined PR so any follow-up can be split into independently reviewable changes. The current branch changes the existing-user color default, still depends on a template-image tint path that does not solve the reported macOS behavior, treats every secondary quota as weekly, and adds unlocalized controls. Separate provider-aware time-window and icon-rendering proposals with compatible defaults and current UI proof would be easier to validate and land. |
evidence from my fork
Important
My b - i thought this got picked up with the latest release. also perf on the latest release isn't great - idk if you've noticed.
These are the features I still think are worthwhile. I like the color in the mac menubar! Not enough apps are utilizing that in macos26
Note
the rest of the summary + other subheaders are claude gen'd
summary
Three small, opt-friendly menu-bar features (all used in my fork), plus a macOS 26.4 build fix.
1. Color-coded menu bar icons —
Advanced ▸ "Color-coded icons"(default on)Tints the menu-bar usage icon green → orange → red based on session usage so you can read pressure at a glance.
UsageColorLevel.tintColor(for:)interpolates the color from the primary window's used percent.StatusItemControllericon paths (merged + per-provider). The tint is part of the icon cache key and the render-skip signatures, so it doesn't break the existing render-coalescing.contentTintColor. So when a tint is active,IconRenderer.makeIcon(tintColor:)draws the shapes directly in the tint color and marks the image non-template (RGB pixels survive). On older macOS the icon stays a template and is tinted via the button'scontentTintColoras before. AeffectiveAppearanceobserver (macOS 26+) re-renders so the dynamic system colors resolve correctly on dark/light switches.2. Separator style —
Display ▸ "Separator"(dot/pipe, default dot)Lets you pick the character between percent and pace in the
bothmenu-bar display mode (e.g.45% · +5%vs45% | +5%).3. Build fix: Swift 6.2.3 / macOS 26.4 SDK
Separate first commit. The nested
makeTitle()inAccountSwitcherView.compactButtonTitlecaptured mutablevars, which crashes swift-frontend (IRGen SIGABRT) on the current toolchain. Reworked to pass the widths as parameters — no behavior change. Without this,maindoesn't compile here, so it's bundled to keep the branch buildable; happy to split it into its own PR if you'd prefer.4. Time-window selection —
Display ▸ "Time windows"Independently choose whether the menu-bar percent and pace values track the rolling session window (~5h for Claude/Codex) or the weekly window. Two segmented pickers, gated on the active display mode. Defaults preserve current behavior (percent = session, pace = weekly), so nothing changes unless you opt in.
MenuBarTimeWindowenum (session/weekly) + two persisted settings.StatusItemControllerselects the window per setting: session →menuBarPercentWindow/UsagePaceText.sessionPace; weekly →secondary(with codex-projection / abacus fallbacks) /UsageStore.weeklyPace.Notes
UsageColorLevelTests,MenuBarSeparatorStyleTests, and a time-window settings round-trip test.swift build,swift test(new tests), and./Scripts/lint.sh lintall pass.🤖 Generated with Claude Code