Skip to content

feat(usage): budget-aware coloring for the Extra Usage widgets#468

Open
zachthedev wants to merge 2 commits into
sirmalloc:mainfrom
zachthedev:feat-budget-colors
Open

feat(usage): budget-aware coloring for the Extra Usage widgets#468
zachthedev wants to merge 2 commits into
sirmalloc:mainfrom
zachthedev:feat-budget-colors

Conversation

@zachthedev

Copy link
Copy Markdown
Contributor

What

Implements #467: optional budget-aware coloring for the three Extra Usage widgets
(extra-usage-used, extra-usage-remaining, extra-usage-utilization), so the value visibly
shifts color as you approach your monthly spend limit instead of sitting in one static color.

Design

  • New optional Widget hook getDynamicColor(item, context): string | undefined (src/types/Widget.ts).
    A widget can override its own foreground color from live render data.
  • The renderer prefers it over item.color ?? defaultColor at both per-widget color sites (the normal
    path and the powerline path). The global overrideForegroundColor still takes precedence, so existing
    precedence is unchanged, and any widget that does not implement the hook renders exactly as before.
  • The three Extra Usage widgets implement it, keyed on the API utilization percentage: green below the
    warn threshold, yellow in the warn band, red at the critical threshold and above.

Opt-in and configuration

  • Off by default. Toggle per widget with the new (b)udget colors keybind in the editor (it sets a
    budgetColors metadata flag). With the flag off, the widget renders in its static configured color
    exactly as today.
  • The three tier colors default to plain green / yellow / red and are each overridable per widget
    via metadata (budgetColorOk / budgetColorWarn / budgetColorCrit), accepting the same color
    formats as item.color (named, ansi256:N, hex:RRGGBB).
  • Thresholds: warn at 75%, critical at 90% utilization.

Default behavior unchanged

Without the opt-in flag, every widget renders exactly as it does now: the dynamic color resolves to
undefined and the renderer falls through to the existing item.color ?? defaultColor.

Tests

  • New budget-color suite: threshold escalation, custom hex overrides, the opt-in toggle, the keybind
    and editor modifier, and each widget's getDynamicColor.
  • Updated the three Extra Usage keybind assertions for the new (b) bind.
  • Full suite: 1597 pass, lint clean.

Notes

Happy to split into two commits for review (interface + renderer hook, then the widget implementations)
if you would prefer to take it in pieces.

Closes #467

Adds an optional Widget.getDynamicColor(item, context) hook so a widget can override its foreground color from live data. The renderer prefers it over the configured color at both per-widget color sites (normal and powerline); the global overrideForegroundColor still wins, and widgets that do not implement the hook are unaffected.

The Extra Usage widgets (used, remaining, utilization) opt in via a (b) toggle and the budgetColors metadata flag and shift green to yellow to red as the monthly budget nears exhaustion (warn at 75 percent, critical at 90 percent utilization). The three tiers default to plain green/yellow/red and are overridable via budgetColorOk/Warn/Crit hexes. Default behavior is unchanged. Refs sirmalloc#467.
A budget-color suite (threshold escalation, custom hex overrides, the opt-in toggle, the (b) keybind and editor modifier, and each Extra Usage widget getDynamicColor) plus the three keybind-assertion updates for the new bind.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

feat: budget-aware coloring for the Extra Usage widgets

1 participant