Proposal: Custom Themes + Light/Dark/System Mode + Contrast Fixes

[brooksc]

I'd like to propose some improvements around themes. I've found none of the themes are optimal for myself and so I wanted to create a way to support custom themes - and use AI to help define them. Below are the issues I see and how I'd propose to solve them.

Problem 1: Three built-in themes fail WCAG AA contrast

Running an automated contrast audit (4.5:1 ratio for normal text) shows three themes where --accent / --border-focus are too light against their background:

Theme	Current	Fixed	Ratio before → after
classic	#4c6fff	#4267ff	4.17 → 4.55:1
islands-dark	#548af7	#286cf5	3.30 → 4.61:1
islands-light	#3574f0	#2c6def	4.27 → 4.60:1

Small hex changes, visually minimal difference, but fixes the accessibility gap.

Problem 2: No OS-aware appearance mode

The app has 12 presets (11 dark, 1 light — islands-light) but no way to automatically follow the OS light/dark preference. Users who switch between light and dark OS modes have to manually change the theme.

Proposed solution: A three-way selector — Light / Dark / System — at the top of a new Themes settings tab. System mode watches prefers-color-scheme and switches between a user-chosen light preset and dark preset automatically. Fully backward-compatible: existing users are migrated to the correct mode on first launch.

Problem 3: No custom theme support

There's no way to create themes beyond the 12 built-ins.

Proposed solution: A custom theme editor in the Themes tab. Themes are defined as YAML (CSS variable overrides + a terminal background color) and stored as individual files in userData/themes/. The editor includes an AI prompt generator to help users design themes, inline WCAG contrast validation, clone-from-preset, and edit/delete. Custom themes work with the Light/Dark/System mode selector so you can assign a custom theme to each slot.

Questions for you:

1. Are you open to WCAG contrast fixes to the built-ins? (Small, low-risk)
2. Do you agree with the Light/Dark/System mode approach?
3. Is custom theme support something you'd want in core, or would you prefer it as an optional/experimental feature?

Next steps:

If you are aligned on the above, I'd submit 3 PRs.

1. Built-in theme contrast fixes as a small standalone PR
2. Light/Dark/System appearance mode + persistence migration + tests
3. Custom themes YAML editor/storage/validation

I did jump the gun and have a version implemented, I had submitted it with #112 but have closed it out and wanted to step back and get your input on this before resubmitting it.

[johannesjo]

Hey there! Thanks for opening this up!

The contrast fixes sound look a important fix appearance-wise!

For theming I'd prefer just using css variables rather than yaml files to be honest. I think it would add a layer that is not really needed. Css variables should be powerful enough to do everything. I also think that requiring a light mode for every theme might be too much. Most devs I use dark themes. I think to have a light theme option is important, but requiring a light theme doesn't feel right. Neither vscode nor intellij do this out of the box, which is telling imho.

What do you think?

[brooksc]

To clarify, if you want a dark theme -- you can stick with that. There are three options

1. Dark theme always
2. Light theme always
3. Dark/Light theme based on the system

This is exactly what VS Code does and most other apps -- for example

I'll proceed with submitting 3 PRs on this

1. Contrast fix
2. Moving themes to a tab within settings - to support the future PR growth of user defined themes
3. User defined themes -- using CSS not YAML

Once you review them of course let me know if there are any other changes you'd like!

[johannesjo]

Ah this makes sense! Have been a long time intellj idea user and there you need a plugin for this :) Looking forward to see this in action!