Feature proposal: Custom color themes + live config reload

[AlexanderNZ]

Hi there! 👋

First off, thanks for building xleak — it's a really nice tool. Clean architecture, fast rendering, and the ColorScheme struct is beautifully designed.

I've been looking at the source and noticed a couple of features that would be relatively straightforward to add given how well the code is already structured. Wanted to check if you'd be open to contributions in these areas before I start work:

1. Custom Color Themes via config.toml

The existing ColorScheme struct (17 fields, cleanly decoupled from the Theme enum) maps almost 1:1 to a TOML table. This would let users define their own themes to match their terminal palette.

Example config (~/.config/xleak/config.toml):

[theme]
name = "tokyonight"

[theme.colors]
background = "#1a1b26"
foreground = "#c0caf5"
header_bg = "#24283b"
header_fg = "#7aa2f7"
selected_bg = "#33467c"
selected_fg = "#c0caf5"
border = "#565f89"

Implementation-wise, this would be ~150-200 lines — add serde derive to ColorScheme, a config loader, and a --theme CLI flag. The hard part (clean color abstraction) is already done.

2. Live Config Reload

With the existing 100ms event loop poll, adding a file watcher (via the notify crate) for the config file would be ~60-80 lines. When the config changes, reload the ColorScheme and the next render tick picks it up automatically. This is great for theme tweaking — edit the TOML, save, see the result instantly.

---

Both features are additive and wouldn't change any existing behavior — the built-in themes would remain as defaults.

Happy to submit a PR if you're interested! Would love to hear your thoughts on scope/approach before diving in.

[AlexanderNZ]

One more thought on the config design — how multiple themes could coexist with the built-in ones.

Single custom theme (simplest case)

A user who just wants to tweak colors for their terminal would add one theme to their config:

default_theme = "tokyonight"

[[themes]]
name = "tokyonight"
background = "#1a1b26"
foreground = "#c0caf5"
header_bg = "#24283b"
header_fg = "#7aa2f7"
selected_bg = "#33467c"
selected_fg = "#c0caf5"
border = "#565f89"

Many custom themes

Power users (or people who sync themes across tools) can define as many as they want and switch between them:

default_theme = "tokyonight"

[[themes]]
name = "tokyonight"
background = "#1a1b26"
foreground = "#c0caf5"
header_bg = "#24283b"
header_fg = "#7aa2f7"
selected_bg = "#33467c"
selected_fg = "#c0caf5"
border = "#565f89"

[[themes]]
name = "bioluminescence"
background = "#011423"
foreground = "#CBE0F0"
header_bg = "#0a2840"
header_fg = "#0FC5ED"
selected_bg = "#214969"
selected_fg = "#CBE0F0"
border = "#214969"

[[themes]]
name = "matrix"
background = "#0a0a0a"
foreground = "#00ff41"
header_bg = "#0d1a0d"
header_fg = "#00cc33"
selected_bg = "#1a2e1a"
selected_fg = "#00ff41"
border = "#003300"

Then xleak --theme matrix data.xlsx or a keybind to cycle at runtime.

Stock themes alongside custom ones

The built-in themes (Dark, Light, Monokai, etc.) would remain as defaults and always be available. Custom themes just extend the list — if a custom theme has the same name as a built-in, the custom one wins. So the resolution order would be:

1. Custom themes from config.toml
2. Built-in themes (fallback)

This means default_theme = "Dark" works out of the box with zero config, and users who want their own palette just add [[themes]] entries without losing access to the stock ones.

Why this matters for dotfiles/tool orchestration

My use case: I run a central theme-switch <name> script that propagates one theme name to SketchyBar, Neovim, WezTerm, JankyBorders, etc. Each tool owns its own color definitions internally — the script just tells each tool which name to activate. For xleak, that would mean writing default_theme in the config file and xleak picks it up on next launch (or immediately with live reload).

This "each tool owns its colors, orchestrator just passes the name" pattern works really well in practice and avoids needing a single shared color format across tools with different color representations.

[bgreenwell]

Hey @AlexanderNZ, thanks for the detailed writeup and for reading the source first — that's appreciated.

Custom themes via config.toml — yes, would love this. The [theme] section already exists in config.toml, so this is a natural extension. One thing worth flagging: hex → ratatui Color conversion requires truecolor support, so graceful fallback to named/ANSI colors would be good to have for broader terminal compatibility.

Live reload — I'd skip this for now. The 100ms poll is keyed to input events, and notify adds non-trivial cross-platform complexity for a dev-only convenience. Theme cycling (t keybind) covers the live-switching use case well enough, IMO.

If you want to open a PR, that'd be great — I'm in the middle of a teaching semester and won't get to this until summer wraps up, so a contribution would be very welcome. Happy to review as you go.

[AlexanderNZ]

Hey @bgreenwell - raised #47

I decided to deal with terminal compatibility in a separate PR. I also decided to drop the live-reload and stick with t :)

I will need to do a bit of research before I deal with the terminal compatibility work as I've not had to do stuff like that before. Let me know if you have any feedback on that PR, You mentioned looking at this over summer so I'll check back in intermittently to see how things are going.

Cheers!