Provide theme for light mode

eschnett commented

2026-03-14 07:14:43 -07:00

(Migrated from github.com)

I looked at the available themes (in TachikomaDemos/launcher), and all are quite difficult to read on my screen. I am using light mode, i.e. a light background, and the current themes all use several colours that are too close to white.

kahliburke commented

2026-03-14 14:15:01 -07:00

(Migrated from github.com)

@eschnett - I'm dark mode 100%, so it's reflecting my bias. I would welcome a contribution of something like:

A set of light mode themes which you curate
A setting toggle toggles/modifies the existing themes into a light theme mode
A setting which switches between selection of dark theme vs light theme modes
etc.

Any toggles should have a user persisted preference via LocalPreferences, and be placed into the Tachikoma settings controls (opened with ctrl-s by default)

There would be a related issue which is that pixel canvases are rendered on a dark background, the light theme mode would need to be integrated into this system as well.

Happy to have a working session on any of these things if you would like.

@eschnett - I'm dark mode 100%, so it's reflecting my bias. I would welcome a contribution of something like: 1. A set of light mode themes which you curate 2. A setting toggle toggles/modifies the existing themes into a light theme mode 3. A setting which switches between selection of dark theme vs light theme modes 4. etc. Any toggles should have a user persisted preference via LocalPreferences, and be placed into the Tachikoma settings controls (opened with ctrl-s by default) There would be a related issue which is that pixel canvases are rendered on a dark background, the light theme mode would need to be integrated into this system as well. Happy to have a working session on any of these things if you would like.

eschnett commented

2026-03-17 13:20:14 -07:00

(Migrated from github.com)

Here is an idea I have. Define a few functions:

function to_256(c::ColorRGB)
    diff(a::ColorRGB, b::ColorRGB) = abs(Int(a.r - b.r)) + abs(Int(a.g - b.g)) + abs(Int(a.b - b.b))
    n = argmin(diff(c, to_rgb(Color256(n))) for n in 0x00:0xff)
    Color256(n)
end
to_256(c::Color256) = c

inverse_color(c::ColorRGB) = ColorRGB(255 - c.r, 255 - c.g, 255 - c.b)
inverse_color(c::Color256) = inverse_color(to_rgb(c))

and then write e.g.

const KOKAKU_LIGHT = Theme(
    "kokaku_light",
    to_256(inverse_color(Color256(234))),  # bg: very dark blue-gray
    to_256(inverse_color(Color256(66))),   # border: dark cyan
    to_256(inverse_color(Color256(75))),   # border_focus: steel blue
    to_256(inverse_color(Color256(252))),  # text: light gray
    to_256(inverse_color(Color256(242))),  # text_dim: medium gray
    to_256(inverse_color(Color256(159))),  # text_bright: pale cyan
    to_256(inverse_color(Color256(75))),   # primary: tachikoma blue
    to_256(inverse_color(Color256(68))),   # secondary: muted blue
    to_256(inverse_color(Color256(117))),  # accent: bright cyan
    to_256(inverse_color(Color256(114))),  # success: sage green
    to_256(inverse_color(Color256(221))),  # warning: yellow
    to_256(inverse_color(Color256(168))),  # error: rose
    to_256(inverse_color(Color256(81))),   # title: sky blue
)

This would automate creating light themes by just inverting the dark themes. The results are readable – but of course the colours are "wrong", instead of a blue-ish style, the kokaku_light theme is deep purple-ish. The error colour is now green-cyan-ish. All very visible, though.

It might also be possible to auto-detect the terminal background colour by using OSC 11, and to switch between light and dark themes automatically. I don't know whether this is a good idea.

Here is an idea I have. Define a few functions: ``` function to_256(c::ColorRGB) diff(a::ColorRGB, b::ColorRGB) = abs(Int(a.r - b.r)) + abs(Int(a.g - b.g)) + abs(Int(a.b - b.b)) n = argmin(diff(c, to_rgb(Color256(n))) for n in 0x00:0xff) Color256(n) end to_256(c::Color256) = c inverse_color(c::ColorRGB) = ColorRGB(255 - c.r, 255 - c.g, 255 - c.b) inverse_color(c::Color256) = inverse_color(to_rgb(c)) ``` and then write e.g. ``` const KOKAKU_LIGHT = Theme( "kokaku_light", to_256(inverse_color(Color256(234))), # bg: very dark blue-gray to_256(inverse_color(Color256(66))), # border: dark cyan to_256(inverse_color(Color256(75))), # border_focus: steel blue to_256(inverse_color(Color256(252))), # text: light gray to_256(inverse_color(Color256(242))), # text_dim: medium gray to_256(inverse_color(Color256(159))), # text_bright: pale cyan to_256(inverse_color(Color256(75))), # primary: tachikoma blue to_256(inverse_color(Color256(68))), # secondary: muted blue to_256(inverse_color(Color256(117))), # accent: bright cyan to_256(inverse_color(Color256(114))), # success: sage green to_256(inverse_color(Color256(221))), # warning: yellow to_256(inverse_color(Color256(168))), # error: rose to_256(inverse_color(Color256(81))), # title: sky blue ) ``` This would automate creating light themes by just inverting the dark themes. The results are readable – but of course the colours are "wrong", instead of a blue-ish style, the kokaku_light theme is deep purple-ish. The error colour is now green-cyan-ish. All very visible, though. It might also be possible to auto-detect the terminal background colour by using OSC 11, and to switch between light and dark themes automatically. I don't know whether this is a good idea.

goerz commented

2026-03-17 14:31:53 -07:00

(Migrated from github.com)

+1 one on auto-detecting the terminal background color. There are a few methods that generally work, both via escape codes, or via environment variables (COLORFGBG is a classic one, but sometimes specific terminal emulators set additional variables).

It might also be interesting to experiment with a monochrome "color" (or rather, no-color) scheme by default that simply uses the "default" foreground and background color of the terminal. Something like Sessions might go a long way in monochrome, even if that doesn't allow for things like syntax highlighting of Julia code or fancy colorful plots.

Beyond that, you'd probably want a preferences-file to choose a color theme or to set specific colors. Incidentally (mixing this issue with a concern for Sessions specifically): can I switch between the existing color schemes in Sessions, or define my own colors in some file that I could then experiment with?

+1 one on auto-detecting the terminal background color. There are a few methods that generally work, both via escape codes, or via environment variables (`COLORFGBG` is a classic one, but sometimes specific terminal emulators set additional variables). It might also be interesting to experiment with a monochrome "color" (or rather, no-color) scheme by default that simply uses the "default" foreground and background color of the terminal. Something like `Sessions` might go a long way in monochrome, even if that doesn't allow for things like syntax highlighting of Julia code or fancy colorful plots. Beyond that, you'd probably want a preferences-file to choose a color theme or to set specific colors. Incidentally (mixing this issue with a concern for `Sessions` specifically): _can_ I switch between the existing color schemes in `Sessions`, or define my own colors in some file that I could then experiment with?

kahliburke commented

2026-03-17 22:07:15 -07:00

(Migrated from github.com)

I don't know specifically about whether Sessions exposes the default keybindings which includes Ctrl-\ for opening the theme selector.

I'm not going to implement the dark/light. mode detector at this time. If you want to implement it and test it in all the browsers, I'd consider a patch. It just seems like a fiddly thing for not that much gain. You'll be able to select your alignment (dark/light) and then have a set of themes for those modes. Theme and alignment selection is persistent by default. (theme already was through LocalPreferences), but that can be app specific.

Please try in the new release and provide any feedback on whether it works for your needs!

I don't know specifically about whether Sessions exposes the default keybindings which includes Ctrl-\ for opening the theme selector. I'm not going to implement the dark/light. mode detector at this time. If you want to implement it and test it in all the browsers, I'd consider a patch. It just seems like a fiddly thing for not that much gain. You'll be able to select your alignment (dark/light) and then have a set of themes for those modes. Theme and alignment selection is persistent by default. (theme already was through LocalPreferences), but that can be app specific. Please try in the new release and provide any feedback on whether it works for your needs!

👍 1

Rows
Columns

Provide theme for light mode #15