How exactly do themes work?

[mainrs]

I've been trying to wrap my head around them.

1. Why does zellij need its own config? Wouldn't using the same values as the terminal that starts zellij be the best option? And then rely on those values instead of having to (re-define in most cases) the setup that is already present?

2. It seems that colors are not "absolute". They sometimes get mixed together. See #769. Is that intentional? Is there a way to account for this without needing to spin up a calculator?

[a-kenji]

Hey @mainrs thank you for taking the time opening this issue!

Why does zellij need its own config? Wouldn't using the same values as the terminal that starts zellij be the best option? And then rely on those values instead of having to (re-define in most cases) the setup that is already present?

This is not really something we can do and also provide a readable UI at the same time.

It seems that colors are not "absolute". They sometimes get mixed together. See https://github.com/zellij-org/zellij/issues/769. Is that intentional? Is there a way to account for this without needing to spin up a calculator?

I am not sure what is happening there, this is a weird bug that should not happen.

See also #675 which is probably related.

[imsnif]

Also @kunalmohan is doing some work on themes as we speak. I think things should be better and more formalized in the near future.

[fisadev]

I'm trying to customize my own themes, and also having a hard time understanding how they work. Specially, what is each one of the colors, where are they used, etc. And having to map a color name to something that is not really that color but a different one, adds to the confusion.

IMHO, instead of something like this:

    red: /some green numbers/
    green: /blue numbers/
    yellow: /gray numbers/
    blue: /orange numbers/
    ...

it would be far easier to customize if themes were expressed something like this:

    tab-title-bg: /some green numbers/
    tab-title-fg: /blue numbers/
    pane-border: /gray numbers/
    help-bg: /orange numbers/
    ...

(using invented names as examples)

[imsnif]

Hey @fisadev - while I understand the frustration, the way the themes are right now is in order to maximize compatibility with other platforms, which in our world tend to map one color to another to have the theming effect.

What you suggest might be problematic in the long run, since our UI will invariably change and other developers write various plugins that will display different or additional parts of the UI for which they'll also want to use the palette.

[chris-morgan]

The current approach seems fairly strongly antithetical to both actual theming and compatibility, and seems to be quite antagonistic to light and high-contrast terminals, too. (I’m just trying out Zellij now, and in my high-contrast light terminal I can’t get anything even vaguely close to what I’d like—it’s quite impossible. Even the closest I can get requires nonsense like “black is actually lightish blue” and “white is black”.)

What fisadev is suggesting is the only sane way. It won’t cause problems in the long run if you (a) choose a sane set of stock values, and (b) allow custom-named properties, ideally with automatic fallback lookup (e.g. plugin says “I have a theme swatch named ‘plugin-a-foo’ which defaults to ‘tab-title-bg’”). Many systems have worked this way. It tends to last very well. Whereas the current approach is already disastrously misleading, as you’ve named the swatches with mostly traditional colour names (“red”, “black”, “fg”, &c.) that may bear no resemblance to their actual colours.

Also related: #1027.

[ModProg]

Even if you insist on keeping colors (for most cases I would rather have something like emphesize, accent , warn, error, ...), a big improvement would be gotten if one where able to specify a fg and bg variant for each color that will be used for text. That would for example solve the problem of not being able to have decent light themes, because some places use white for the text color and some use fg.

[mainrs]

[...] and seems to be quite antagonistic to light and high-contrast terminals, too.

yep, i'm in the same boat. i cannot get light theming to work properly. i will probably fork the project and make the theming match my own use-case.

[ModProg]

I read somewhere something about reworking the config, but not sure what is meant by this.

If there are no conflicting efforts, I might look into making a PR for a theming focused on avoiding these conflicts of having unreadable text in light themes.

[ModProg]

I would propose something like this:

themes:
  default:
    background:
      color: "#000000"
      text: &background.text "#dadada"
      error: &background.error "#ff4040"
      warn: &background.error "#ff8c40"
      emphasis: &background.error "#8bff40"
    surface:
      color: "#272727"
      text: *background.text
      error: *background.error
    error:
      color:
      text:
    warn:
      color:
      text:
    emphasis:
      color:
      text:
    primary:
      color:
      text:
    secondary:
      color:
      text:
    ternary:
      color:
      text:

For any color, both the background color and the foreground text are mandatory. The additional foreground colors: error, warn, emphasis... are optional and fall back to text to ensure readability.

I used yaml anchors in this example to reuse the text colors in the surface definition, but this could also be replaced by allowing a "reference" i.e. just a text saying "background.text" or by allowing to specify a base to extend:

background:
  color: "#000000"
  #...
surface:
  base: background
  # only specify overrides

This could be done both in a backward compatible way by having a mapping making e.g. red the default for error and green the default for primary... and allow extending by e.g. introducing additional "secondary" colors that can be set to "secondary" by default.

[dsully]

+1 - I just started to use zellij, and was surprised by the out-of-box behavior and lack of this customizability.

[xosxos]

Yeah, Zellij renders some programs completely unusable due to hijacking the theme in weird ways. This problem is present in quite many cli applications such as the slides program and broot file tree navigator for example. I would consider this a pretty major bug.

Attached picture is an example of presenting slides with the slides program from the terminal with zellij theme set on default. On the left is alacritty, middle is zellij in alacritty and right is tmux in alacritty.

Alacritty version 0.10.1 and Zellij version 0.34.4

[imsnif]

Hey @xosxos - could you please help me understand how this issue relates to the issue at hand?

[xosxos]

Just a gut feeling it might be related to how themes are handled in general or to #769. I can also file a new issue when I get around to catching the logs required for filing issues.

edit: tried switching themes and it actually did not affect these colors that are rendered wrong, so yeah, probably not related to this

[0rphee]

The current approach seems fairly strongly antithetical to both actual theming and compatibility, and seems to be quite antagonistic to light and high-contrast terminals, too. (I’m just trying out Zellij now, and in my high-contrast light terminal I can’t get anything even vaguely close to what I’d like—it’s quite impossible. Even the closest I can get requires nonsense like “black is actually lightish blue” and “white is black”.)

What fisadev is suggesting is the only sane way. It won’t cause problems in the long run if you (a) choose a sane set of stock values, and (b) allow custom-named properties, ideally with automatic fallback lookup (e.g. plugin says “I have a theme swatch named ‘plugin-a-foo’ which defaults to ‘tab-title-bg’”). Many systems have worked this way. It tends to last very well. Whereas the current approach is already disastrously misleading, as you’ve named the swatches with mostly traditional colour names (“red”, “black”, “fg”, &c.) that may bear no resemblance to their actual colours.

Also related: #1027.

I completely agree with this comment. Coming from helix, this is a big frustration. The themes there are somewhat complicated, but they are (mostly) very precise in how they work. Maybe you like to have this particular ui item with a distinct color?, well, then you can, without affecting other similar ui elements. You could even have a a rainbow-themed editor, with any number of colors you want. What? you mostly like the (for example) builtin gruvbox theme, but you want to change some particular quirk? well then, no problem, just change the styling of "ui.element.color" without hassle!

However, I understand that for zellij, (since it may not require as many styling options as an editor), this might be a bit, overkill, and one more thing to maintain, but I think it would be worth it. If talking about compatibility, maybe there's room to keep available the color palette to fallback on just in case, and warning users, that x or y theme may not be rendered properly without x or y terminal emulator feature.

Just my (probably wrong) thoughts anyway. Love the project so far! Thanks for all your work!

[imsnif]

There's some more discussion about this subject here: https://github.com/zellij-org/zellij/issues/2297 (tldr: right now this is awaiting a detailed proposal and implementation).