Problem Statement
ticker currently limits user customization to a small subset of UI color elements (text, text-light, text-label, text-line, text-tag, background-tag). However, important interface components—such as the bottom summary/status bar, change indicators, borders, and inactive elements—inherit hard-coded ANSI colors. This restricts integration with themed environments (e.g., Rosé Pine, Gruvbox, Solarized) and prevents full visual coherence when used in color-managed terminals or themed dashboards.
Proposed Solution
Extend the colors configuration struct in config/config.go to include new optional keys for additional UI regions and semantic roles, for example:
colors:
summary-text: "#e0def4"
summary-background: "#26233a"
gain: "#9ccfd8"
loss: "#eb6f92"
border: "#403d52"
highlight: "#f6c177"
These would be accessed in ui/view.go (and other renderers) via the existing config.Colors object, with sensible fallbacks to current ANSI defaults when unspecified. This maintains backward compatibility while enabling full theme customization through YAML.
Alternatives
- Relying on terminal color tables or ANSI overrides (works partially but not portable).
- Using wrappers like
grc or colout to post-process output (inefficient and brittle).
- Forking
ticker and editing view.go directly (not maintainable for most users).
Use Cases
- Users applying consistent theming across CLI tools (Rosé Pine, Catppuccin, Gruvbox, etc.).
- Integrations with dashboards or status bars where color control must match existing palettes.
- Accessibility adjustments (high contrast, colorblind-friendly schemes).
Additional Context
Example YAML configuration using Rosé Pine palette:
colors:
text: "#e0def4"
text-light: "#f6c177"
text-label: "#9ccfd8"
text-line: "#c4a7e7"
text-tag: "#31748f"
background-tag: "#26233a"
summary-background: "#1f1d2e"
summary-text: "#e0def4"
gain: "#9ccfd8"
loss: "#eb6f92"
This change would allow full visual parity between ticker and modern CLI ecosystems that emphasize theme consistency.
Problem Statement
tickercurrently limits user customization to a small subset of UI color elements (text,text-light,text-label,text-line,text-tag,background-tag). However, important interface components—such as the bottom summary/status bar, change indicators, borders, and inactive elements—inherit hard-coded ANSI colors. This restricts integration with themed environments (e.g., Rosé Pine, Gruvbox, Solarized) and prevents full visual coherence when used in color-managed terminals or themed dashboards.Proposed Solution
Extend the
colorsconfiguration struct inconfig/config.goto include new optional keys for additional UI regions and semantic roles, for example:These would be accessed in
ui/view.go(and other renderers) via the existingconfig.Colorsobject, with sensible fallbacks to current ANSI defaults when unspecified. This maintains backward compatibility while enabling full theme customization through YAML.Alternatives
grcorcoloutto post-process output (inefficient and brittle).tickerand editingview.godirectly (not maintainable for most users).Use Cases
Additional Context
Example YAML configuration using Rosé Pine palette:
This change would allow full visual parity between
tickerand modern CLI ecosystems that emphasize theme consistency.