What problem does this solve?
Right now customizing colors means setting all four hex inputs
individually. A theme_preset input with a few curated named palettes
would make experimentation much easier.
Proposed solution
- Add a
THEME_PRESET optional env var / theme_preset action input
- Define 3-4 built-in presets (e.g. "sunset", "aurora", "mono") as
{recentColorDark, oldColorDark, recentColorLight, oldColorLight} quads
in a PRESETS object
- If
theme_preset is set, use its colors as defaults — but individual
color inputs (recent_color_dark, etc.) should still override the
preset if explicitly set, so presets are a convenience, not a
restriction
- Document available presets in the README inputs table
Alternatives considered
Could instead ship presets purely as documentation (copy-paste color
quads in the README) rather than code — simpler, but less discoverable.
Worth a quick discussion before starting.
What problem does this solve?
Right now customizing colors means setting all four hex inputs
individually. A
theme_presetinput with a few curated named paletteswould make experimentation much easier.
Proposed solution
THEME_PRESEToptional env var /theme_presetaction input{recentColorDark, oldColorDark, recentColorLight, oldColorLight} quads
in a
PRESETSobjecttheme_presetis set, use its colors as defaults — but individualcolor inputs (recent_color_dark, etc.) should still override the
preset if explicitly set, so presets are a convenience, not a
restriction
Alternatives considered
Could instead ship presets purely as documentation (copy-paste color
quads in the README) rather than code — simpler, but less discoverable.
Worth a quick discussion before starting.