Theme definition

[DeaconDesperado]

Draft implementation of the specification laid out in #2297. Would love feedback on this!

Rough outline of the changes:

• Introduces a new struct, Styling, and the necessary protobuf records to match the spec from [Proposal] New theme definition spec #2297
• Implements KDL deserialization for Styling
• Provides bidirectional conversion for Styling <-> Palette in order to preserve backward compatibility for themes:
  • Assignment of colors from the old palette to the new spec was reconstructed gradually by manual comparison.
  • In some instances the same older named color may be used in multiple places (the new specification is more flexible and has more assignable styles, this only affects the default where user still has a Palette in their config).
• Preserve backward compatibility for plugins:
  • Styling -> Palette conversion is performed in the plugin_api layer, so the older message format is still propagated to plugins.
• Replace all references to named colors with style specifications

Open questions / notes

client_id_to_colors

This function is used to colorize pane frames and cursors in multi-user sessions. While mentioned in some of the comments, the proposed specification in #2297 didn't explicitly lay these colors out, and there are (presently) 10 of them (larger in number than the other specs). We could consider adding a separate style block for these, repurposing some of the emphases from frame_unselected, or using some sane defaults? This draft presently sets them to values from crate::shared::colors for the time being.

Configuration shape

KDL prohibits anonymous nodes, and lists are represented as sequential values after the node name. In order to support all three representations of color presently used (single digit, 3 digit rgb, hex) the style specifications all are named individually, and macros from the original Palette are reused to deserialize the color, EG:

text_unselected {
  base "#DCD7BA"
  emphasis_1 "#ACD7CD"
  emphasis_2 "#DCD8DD"
  emphasis_3 "#DCD899"
  emphasis_4 "#ACD7CD"
  background "#16161D"
}

It's arguably a bit redundant to have these indexes named sequentially this way? It might be possible to consolidate all the emphases to one list, but then that one node would need to be extracted into all 4 indexes somehow, which presents the prospect of mixing the EightBit/RGB/Hex representations... WDYT?

Currently, Styling's members are stored as fixed length arrays: it felt like a reasonable way to preserve the ability to add more colors in the future if needed. An alternative could be this structure though.

UI Components

Given that I'm only just getting familiar with the codebase, I opted to make these changes in place without also doing a migration of plugins to the various UI components 😅 . The coloration should be consistent however, only preserving differences where they are an artifact of the present implementation.

An example: When using simplified_ui, the ribbon implemented directly in the status-bar plugin uses alternating background colors to differentiate "tabs", whereas the UI component (eg in session-manager) uses divider spacers colored to match the terminal background. Where encountered, these kinds of differences are preserved (for now).

ThemeHue + PaletteSource

The swap of foreground/background based on ThemeHue is preserved only when converting a Palette to a Styling. The only place I could find this value to be set was in this function, which doesn't seem to be called anywhere. Perhaps it's leftover from an earlier implementation? I seemed to uncover similar for PaletteSource. Not sure if I'm missing something here...

Strider

I was unfortunately unable to do as much vetting of strider specifically, encountered #3064 when trying to test it out. Might require some help with this.

Still TODO

In addition to incorporating any feedback, still need to:

• Update test suites that use snapshot assertion (temporarily ignored here)
• Investigate any e2e test suites that need to be updated
• Document the new theme KDL and update the examples
• Rebase and clean up commit messages
• Might make sense to extend the zellij convert-theme utility to migrate existing configurations to the new format?

Screenshots

Comparison of default theme (left new, right old)

Welcome screen

Frameless layout

Run pane exit codes

Simplified UI (no arrow fonts)

Compact layout

[imsnif]

I'm very excited to see this happening!!

Just a heads up: I'm in the process of wrapping up v0.40.0 in the next week or so, so it will take me a short while to get to this. But rest assured, I will! I ask for your patience and thank you again for what seems like a tremendous amount of work!

[glenn-lytx]

Is there a full config example for this? I'd like to grab this and compile it locally to test it out ..

[imsnif]

Hey @DeaconDesperado - amazing and very thorough work here! Thank you for your patience and apologies for taking so long to give you an initial review. I'll try to be faster from now on so we can iterate over this quickly.

If it's alright with you, I prefer to go over the actual code changes once the product side (API, config, spec, behaviour, etc.) has been finalized. I think it'll save both of us some work, because changes in that area can cause sweeping changes in its implementation.

So to your questions:

Open questions / notes

client_id_to_colors

Good catch, we didn't account for these. Perhaps we can add a multiplayer_user_ids section to the theme definition?

Configuration shape

It's arguably a bit redundant to have these indexes named sequentially this way? It might be possible to consolidate all the emphases to one list, but then that one node would need to be extracted into all 4 indexes somehow, which presents the prospect of mixing the EightBit/RGB/Hex representations... WDYT?

I actually like it this way. I understand it can seem a bit redundant, but I think in the context of a theme configuration this is much clearer than emphasis <color_1> <color_2> <color_3> <color_4> - especially considering the different color formatting as you mentioned.

Currently, Styling's members are stored as fixed length arrays: it felt like a reasonable way to preserve the ability to add more colors in the future if needed. An alternative could be this structure though.

I don't have a strong opinion here, so up to you. A few considerations:

1. Performance (unless I'm wildly missing something) is not an issue for this feature whatsoever. So there's no need to be very cognizant of memory copying/cloning (in the context of the fixed-size arrays). Parsing the configuration is an order of magnitude slower, serializing the struct across the wasm boundary is an order of magnitude slower and otherwise sending it between threads is something that happens only on application startup (or configuration change) in which cases there are much slower things that happen as part of the process (eg. loading plugins, rendering, etc.)
2. If you decide to go with fixed-size arrays after all, I'd rather not have them in a public interface, and care needs to be taken in their setters so as not to crash ever if they overflow.
3. I usually prefer to be verbose in these sorts of things. If it were me I'd have a specialized struct similar to the one you mentioned with emphasis_1, emphasis_2, etc. as explicit members. But really - up to you.

UI Components

Given that I'm only just getting familiar with the codebase, I opted to make these changes in place without also doing a migration of plugins to the various UI components 😅 . The coloration should be consistent however, only preserving differences where they are an artifact of the present implementation.

Legit! Let's keep things simple.

ThemeHue + PaletteSource

The swap of foreground/background based on ThemeHue is preserved only when converting a Palette to a Styling. The only place I could find this value to be set was in this function, which doesn't seem to be called anywhere. Perhaps it's leftover from an earlier implementation? I seemed to uncover similar for PaletteSource. Not sure if I'm missing something here...

Yes, these are legacies! It's totally fine to remove them if you want.

Strider

These issues were fixed in v0.40.0 and iirc I even moved lots of stuff to UI components, so I hope this will make things easier!

Anything else I can do to help move this along?

[DeaconDesperado]

@imsnif Thanks for the thorough answers! Will incorporate this feedback and have another go at Strider.

[DeaconDesperado]

@glenn-lytx below is a sample of the themes block I've been using locally (also used in the screenshots), just need to change theme_name to suit:

themes {
  theme_name {
     styling {
          text_unselected {
              base "#DCD7BA"
              emphasis_1 "#ACD7CD"
              emphasis_2 "#DCD8DD"
              emphasis_3 "#DCD899"
              emphasis_4 "#ACD7CD"
              background "#16161D"
          }
          text_selected {
              base "#16161D"
              emphasis_1 "#ffa066"
              emphasis_2 "#16161D"
              emphasis_3 "#16161D"
              emphasis_4 "#16161D"
              background "#9CABCA"
          }
          ribbon_unselected     {
              base "#DCD7BA"
              emphasis_1 "#9CABCA"
              emphasis_2 "#7AA89F"
              emphasis_3 "#ACD7CD"
              emphasis_4 "#DCD819"
              background "#363646"
          }
          ribbon_selected {
              base "#16161D"
              emphasis_1 "#ffa066"
              emphasis_2 "#1A1A22"
              emphasis_3 "#2A2A37"
              emphasis_4 "#363646"
              background "#76946A"
          }
          table_title {
              base "#DCD7BA"
              emphasis_1 "#7FB4CA"
              emphasis_2 "#A3D4D5"
              emphasis_3 "#7AA89F"
              emphasis_4 "#DCD819"
              background "#252535"
          }
          table_cell_unselected {
              base "#DCD7BA"
              emphasis_1 "#DCD7CD"
              emphasis_2 "#DCD8DD"
              emphasis_3 "#DCD899"
              emphasis_4 "#ACD7CD"
              background "#1F1F28"
          }
          table_cell_selected {
              base "#16161D"
              emphasis_1 "#181820"
              emphasis_2 "#1A1A22"
              emphasis_3 "#2A2A37"
              emphasis_4 "#363646"
              background "#76946A"
          }
          list_unselected {
              base "#DCD7BA"
              emphasis_1 "#DCD7CD"
              emphasis_2 "#DCD8DD"
              emphasis_3 "#DCD899"
              emphasis_4 "#ACD7CD"
              background "#1F1F28"
          }
          list_selected {
              base "#16161D"
              emphasis_1 "#181820"
              emphasis_2 "#1A1A22"
              emphasis_3 "#2A2A37"
              emphasis_4 "#363646"
              background "#76946A"
          }
          frame_unselected {
              base "#DCD8DD"
              emphasis_1 "#7FB4CA"
              emphasis_2 "#A3D4D5"
              emphasis_3 "#7AA89F"
              emphasis_4 "#DCD819"
          }
          frame_selected {
              base "#76946A"
              emphasis_1 "#C34043"
              emphasis_2 "#C8C093"
              emphasis_3 "#ACD7CD"
              emphasis_4 "#DCD819"
          }
          exit_code_success {
              base "#76946A"
              emphasis_1 "#A3D5D5"
              emphasis_2 "#76946A"
              emphasis_3 "#76946A"
              emphasis_4 "#76946A"
          }
          exit_code_error {
              base "#C34043"
              emphasis_1 "#DCD819"
              emphasis_2 "#C34043"
              emphasis_3 "#C34043"
              emphasis_4  "#C34043"
          }
    }
  }
}

[glenn-lytx]

@glenn-lytx below is a sample of the themes block I've been using locally (also used in the screenshots), just need to change theme_name to suit:

Awesome, thanks! I'll give it a try

[DeaconDesperado]

Revised this quite heavily with the suggested changes:

• Changed to an explicit struct, StyleDeclaration, in lieu of fixed size arrays + position indexing.
• Introduced a new type MultiplayerColors and handling for multi-user sessions.
• Corrected handling of styles in UI components (previous draft did not properly style tables and lists independent of styling in text).

To validate the behavior of the UI components, I set up a very simple toy example based on rust-plugin-example that just renders all the elements in various states (with silly, but noticeable color differences between states)

Let me know if the high level approach here now looks sound, and then I'll proceed with improving the test coverage for backward compatiblity and the aforementioned product stuff to support migration (docs, possible script to migrate old palette to new themes). Also LMK if we prefer that in a separate PR. Thanks!

[imsnif]

Hey @DeaconDesperado - I'm happy to see the work going on. Kudos on your perseverance and consistency, this looks like quite a great effort!

I'm sorry it's taking me a bit of time to get to this, but rest assured - I plan to ASAP! I have not forgotten nor do I mean to let your work go to waste.

[imsnif]

Hey @DeaconDesperado - this sounds good (though I will as mentioned wait with going over the exact code until we finalize the product stuff).

Including a conversion script is a very nice touch, but assuming we preserve backward compatibility and the existing themes will continue working as expected, I think it's alright. This is mostly meant to allow people to more easily create new themes with greater flexibility.

For the interests of efficiency, I have put aside some time every week on Friday morning CEST to go over this PR. So that you'll know when I'll do the next round and are able to prepare for it. I'll try to be available for quick questions in between so that we can get this going.

What else do you need from me for the time being?

[DeaconDesperado]

@imsnif I didn't find time to put a cap on the sole failing integration test this week, but I was wondering what would be the best way to confirm the outstanding product related points? Would you prefer a description incorporating any changes to what was discussed in #2297 here in the comments, or a separate PR to website repo that includes the user-facing documentation?

In the interest of providing something in time for the Friday review bandwidth you carved out for me (thanks!) I'll try to preemptively give the former here, updated to incorporate all the discussions we've had (this is also what's presently working):

Updated Spec

Wherever colors are specified, they use the existing definition prior to this change, using any of:

• A hexadecimal string
• A triplet of u8 for TrueColor
• A single u8 for a 256 terminal color

A theme consists of a styling block, containing:

StyleDeclarations to configure UI components. Each accepts 6 colors:

• A base color
• 4 emphasis colors (emphasis_1,emphasis_2,emphasis_3,emphasis_4)
• A background color.

Any omitted declarations default to the same fixed colors they would prior to this change (constructed from reverse engineering what named fixed colors mapped to what parts of the UX). In order to make sure the theme is coherent, these declarations cannot be partially defined: if they are specified at all, all 6 colors must be set in them (or return an error at startup). They are:

• text_unselected
• text_selected
• ribbon_unselected
• ribbon_selected
• table_title
• table_cell_unselected
• table_cell_selected
• list_unselected
• list_selected

The following additional StyleDeclarations configure elements of the Zellij UI that are apart from the reusable components. These are distinct from the above only in that they do not accept a background (since for all of them, the text_unselected background would apply). As with above, these default to their existing fixed colors if left undefined, and if they are defined, all colors they expect must be included. They are:

• frame_unselected: Colors the stroke around inactive panes
• frame_selected: Colors the stroke around active panes
• exit_code_success: Colors successful messages for panes started with zellij run
• exit_code_error: Colors error messages for panes started with zellij run

And finally, a key multiplayer_user_colors, which defines ten colors player_1, player_2, player_3 ... player_10. This specification, and the colors within it, are optional. Any omitted will default to the same fixed colors used prior to this change.

Complete example configuration for a named theme

themes {
  my_test_theme {
     styling {
          text_unselected {
              base "#DCD7BA"
              emphasis_1 "#ACD7CD"
              emphasis_2 "#DCD8DD"
              emphasis_3 "#DCD899"
              emphasis_4 "#ACD7CD"
              background "#16161D"
          }
          text_selected {
              base "#16161D"
              emphasis_1 "#ffa066"
              emphasis_2 "#16161D"
              emphasis_3 "#16161D"
              emphasis_4 "#16161D"
              background "#9CABCA"
          }
          ribbon_unselected     {
              base "#DCD7BA"
              emphasis_1 "#9CABCA"
              emphasis_2 "#7AA89F"
              emphasis_3 "#ACD7CD"
              emphasis_4 "#DCD819"
              background "#363646"
          }
          ribbon_selected {
              base "#16161D"
              emphasis_1 "#ffa066"
              emphasis_2 "#1A1A22"
              emphasis_3 "#2A2A37"
              emphasis_4 "#363646"
              background "#76946A"
          }
          table_title {
              base "#DCD7BA"
              emphasis_1 "#7FB4CA"
              emphasis_2 "#A3D4D5"
              emphasis_3 "#7AA89F"
              emphasis_4 "#DCD819"
              background "#252535"
          }
          table_cell_unselected {
              base "#DCD7BA"
              emphasis_1 "#DCD7CD"
              emphasis_2 "#DCD8DD"
              emphasis_3 "#DCD899"
              emphasis_4 "#ACD7CD"
              background "#1F1F28"
          }
          table_cell_selected {
              base "#16161D"
              emphasis_1 "#181820"
              emphasis_2 "#1A1A22"
              emphasis_3 "#2A2A37"
              emphasis_4 "#363646"
              background "#363636"
          }
          list_unselected {
              base "#23CF6D"
              emphasis_1 "#eb34ab"
              emphasis_2 "#eb99ab"
              emphasis_3 "#ebbbab"
              emphasis_4 "#ebddcb"
              background "#1F1F99"
          }
          list_selected {
              base "#ebae34"
              emphasis_1 "#ebcc66"
              emphasis_2 "#fcdd77"
              emphasis_3 "#fddd99"
              emphasis_4 "#ffffff"
              background "#353830"
          }
          frame_unselected {
              base "#DCD8DD"
              emphasis_1 "#7FB4CA"
              emphasis_2 "#A3D4D5"
              emphasis_3 "#7AA89F"
              emphasis_4 "#DCD819"
          }
          frame_selected {
              base "#76946A"
              emphasis_1 "#C34043"
              emphasis_2 "#C8C093"
              emphasis_3 "#ACD7CD"
              emphasis_4 "#DCD819"
          }
          exit_code_success {
              base "#76946A"
              emphasis_1 "#A3D5D5"
              emphasis_2 "#76946A"
              emphasis_3 "#76946A"
              emphasis_4 "#76946A"
          }
          exit_code_error {
              base "#C34043"
              emphasis_1 "#DCD819"
              emphasis_2 "#C34043"
              emphasis_3 "#C34043"
              emphasis_4  "#C34043"
          }
          multiplayer_user_colors {
              player_1 "#C34043"
              player_2 "#C34043"
              player_3 "#C34043"
              player_4 "#C34043"
              player_5 "#C34043"
              player_6 "#C34043"
              player_7 "#C34043"
              player_8 "#C34043"
              player_9 "#C34043"
              player_10 "#C34043"
          }
    }
  }
}

[imsnif]

Hey @DeaconDesperado - thanks for putting this together. This is great and really helps me reviewing this PR quickly. I appreciate the clear communication and your meticulousness!

This looks really good to me and I hardly have any comments. Just a few things:

Any omitted declarations default to the #2297 (comment) (constructed from reverse engineering what named fixed colors mapped to what parts of the UX). In order to make sure the theme is coherent, these declarations cannot be partially defined: if they are specified at all, all 6 colors must be set in them (or return an error at startup).

To make sure I understand this correctly: an entire component can be omitted from the styling (eg. ribbon_unselected), but if a component is declared, all of its colors need to be set otherwise we get an error, right? (if I got this right - this is perfect).

text_selected

Could we make this apply to the mouse-selection and search results too? These happen here: https://github.com/zellij-org/zellij/blob/main/zellij-server/src/panes/grid.rs#L1088 (and a few lines below in the same function)

frame_selected

Could we also add a frame_secondary (I'm open to suggestions for a better name for this one). This is the color the frame changes to when we are in non-normal/locked mode (eg. pane, tab etc.) to let the user know their keyboard input will not be sent to the terminal pane in this mode. This will also in the future be the color of the frame under the mouse when we add mouse movement event tracking (it'll be something like: the frame under the mouse cursor will be this color, and you'll be able to select it and make it focused with a click and maybe do some other stuff like shift-click for multi-select and whatnot).

Otherwise - this looks very good and I'm happy to go forward with this and start reviewing the implementation once you're ready. Fair warning: I'm in the process of revamping the UI of the status-bar to solve the colliding keybindings issue, so I imagine I'm going to create some chaos there for you. I'll do my best to make it minimal and help with the merge afterwards.

Amazing work! Looking forward to iterating more and getting this merged.

ADDENDUM: I realized I didn't see any reference to this, so just to make sure: the old themes will still work, right? We have to remain backwards compatible (I'm even in favor of allowing theme authors to mix the new component declarations into the old color themes if they want, but this is not a must IMO).

[DeaconDesperado]

@imsnif

To make sure I understand this correctly: an entire component can be omitted from the styling (eg. ribbon_unselected), but if a component is declared, all of its colors need to be set otherwise we get an error, right? (if I got this right - this is perfect).

That's correct. I think it makes the most sense to have theme authors always provide a declaration in full or not at all, since partial application of defaults could lead to weird text / background mismatches.

Could we make this apply to the mouse-selection and search results too?

Could we also add a frame_secondary (I'm open to suggestions for a better name for this one).

I'll add these to the punchlist 😄.

I realized I didn't see any reference to this, so just to make sure: the old themes will still work, right?

Yes, there is a From<Palettte> impl that applies the members of Palette retroactively to all the declarations they would have for a Styling. It runs during configuration bootstrapping in the case that the palette key is in the kdl. The plugin integration is via the protobufs, where a new field was added for these declarations, and another set of bidirectional mappings so that plugins are also kept backward compatible.

Edit: As it is currently, the new vs old styles can't be mixed together and are configured disjointly. If your named theme includes a styling node, it uses the new configuration, then fallback to palette, then to absent.

[imsnif]

Yes, there is a From<Palettte> impl that applies the members of Palette retroactively to all the declarations they would have for a Styling. It runs during configuration bootstrapping in the case that the palette key is in the kdl. The plugin integration is via the protobufs, where a new field was added for these declarations, and another set of bidirectional mappings so that plugins are also kept backward compatible.

Edit: As it is currently, the new vs old styles can't be mixed together and are configured disjointly. If your named theme includes a styling node, it uses the new configuration, then fallback to palette, then to absent.

Hey, I couldn't find the declaration in the link and I'm still not up to speed on the implementation details - so just to make sure (because this is a showstopper and I don't want to needlessly add work for you in the end): if I have an arbitrary file (not included in the Zellij repo) that has the old theme declaration with colors, that works now - will it continue working after this?

It's totally fine if we can't mix these declarations, but if that is the case, let's error if they are mixed.

[DeaconDesperado]

Hmm the link does seem to be broken when highlighting the lines.

Yes, they will continue to work without problem. The old format is just mapped into the new one in memory and at runtime when configuration loads.

[DeaconDesperado]

I believe this should now be ready for review. I added a few test cases to validate the configuration works as expected (and errors under the right conditions).

Per our separate discussion in Discord, I removed any commits I had made to the e2e tests in an effort to get them to work with my local setup (we ran into OSX environment-specific issues). Will rely on the CI/CD feedback for these.

[imsnif]

Hey @DeaconDesperado - first off: fantastic work once again! I had a list of things to check on the compatibility/API level and this implementation passed them with flying colors. The [deprecated] annotation for the protobuffers is a really nice touch (I didn't know such a thing existed).

This looks great all in all - I have a first round of rejects. Let's iterate over this a bit and once we're satisfied I'll do a deeper dive into the code

1. Regarding the styling node in the theme definition

I'm not sure if we discussed this before, but would it be possible to get rid of it and have everything flat? I think it'll be nicer for defining themes, eg.:

  my_test_theme {
    text_unselected {
        base "#DCD7BA"
        emphasis_1 "#ACD7CD"
        emphasis_2 "#DCD8DD"
        emphasis_3 "#DCD899"
        emphasis_4 "#ACD7CD"
        background "#16161D"
    }
    text_selected {
        base "#16161D"
        emphasis_1 "#ffa066"
        emphasis_2 "#16161D"
        emphasis_3 "#16161D"
        emphasis_4 "#16161D"
        background "#9CABCA"
    }
}

2. The tab-bar active tab appears wrong

Using the provided theme example from above, I start Zellij and open a new tab.

3. The new "keygroup separator" needs to be themed as well

Might be able to fold it in to one of the existing theme definitions? Otherwise maybe we can add a separate definition for it. You're more in the weeds on this one, so maybe you have an idea? (the orange ribbon in this screenshot). This screenshot is from when the default_mode is locked, but it will now also show every time you enter a mode that is not "normal" or "locked" with the default settings.

4. The session-manager "New Session" Screen appears wrong

This is a screenshot from the test-theme, notice that the up/down arrows do not appear on the selected row, and also the text is not readable (though the latter might be a specific issue with this theme definition?)

5. The session-manager "Resurrect Session" Screen appears wrong

This might be the same issue as 4, but just wanted to mention it here.

Also, there appears to be a separator between table columns (both in a selected and non-selected row). Can we remove it?

Conclusion

I'm very excited to see this moving forward so consistently. The example theme also looks amazing. Looking forward to the next iteration.

[DeaconDesperado]

Thanks! Once I managed to understand how the plugin API works it felt a bit natural to anticipate certain backward compatibility needs there (it's very nicely designed!)

1

We can remove this, yeah. The thought behind it had been that perhaps there could be a separate node colors where named aliases for colors could be declared to be used instead of repeatedly listing the color codes in for each declaration. Since KDL's schema definition doesn't presently support union types, it also felt maybe a bit more future proof to map a single node directly to a struct in case we ever wanted to do KDL schema validation for the configs and need to add other stuff that's configurable via a theme.

2

Pushed two commits to fix this, quick oversight on my part to not backport the same fix from the UI ribbon component into its separate implementations in tab-bar + compact-bar .

3

This presently uses one of the emphasis colors that would map for orange from the older theme definition: ribbon_selected.emphasis_2. Since it has only a single color with no text overlaid, and is active when a mode is selected, I thought maybe we reuse one of the already existing emphases colors since it's semantically close?

4/5

I suspect the disappearing text is in fact the test theme, if you're testing with the one I pasted in the comment earlier I had to rearrange a few definitions. I'll paste a new one in a following comment.

Will definitely look to collapse that extra space between cells as well.

One other thing: in testing some of the existing themes as-is (dracula) I'm noticing that by prohibiting partial application of colors, we might make it impossible to make some elements keep transparency? EG you must provide a background attribute for table_cell_unselectednow, whereas the preceding designs keep this transparent. The difference is more pronouced when using a terminal with background opacity set < 100%:

Dracula original:

Dracula now:

Perhaps it makes sense to make background optional?

[DeaconDesperado]

Updated test theme

themes {
  test_theme {
     styling {
          text_unselected {
              base "#DCD7BA"
              emphasis_1 "#ACD7CD"
              emphasis_2 "#DCD8DD"
              emphasis_3 "#DCD899"
              emphasis_4 "#ACD7CD"
              background "#16161D"
          }
          text_selected {
              base "#16161D"
              emphasis_1 "#ffa066"
              emphasis_2 "#16161D"
              emphasis_3 "#16161D"
              emphasis_4 "#16161D"
              background "#9CABCA"
          }
          ribbon_unselected     {
              base "#DCD7BA"
              emphasis_1 "#9CABCA"
              emphasis_2 "#7AA89F"
              emphasis_3 "#ACD7CD"
              emphasis_4 "#DCD819"
              background "#363646"
          }
          ribbon_selected {
              base "#16161D"
              emphasis_1 "#ff0066"
              emphasis_2 "#ffa066"
              emphasis_3 "#2A2A37"
              emphasis_4 "#363646"
              background "#76946A"
          }
          table_title {
              base "#DCD7BA"
              emphasis_1 "#7FB4CA"
              emphasis_2 "#A3D4D5"
              emphasis_3 "#7AA89F"
              emphasis_4 "#DCD819"
              background "#252535"
          }
          table_cell_unselected {
              base "#DCD7BA"
              emphasis_1 "#DCD7CD"
              emphasis_2 "#DCD8DD"
              emphasis_3 "#DCD899"
              emphasis_4 "#ACD7CD"
              background "#1F1F28"
          }
          table_cell_selected {
              base "#16161D"
              emphasis_1 "#181820"
              emphasis_2 "#1A1A22"
              emphasis_3 "#2A2A37"
              emphasis_4 "#363646"
              background "#DCD7BA"
          }
          list_unselected {
              base "#23CF6D"
              emphasis_1 "#eb34ab"
              emphasis_2 "#eb99ab"
              emphasis_3 "#ebbbab"
              emphasis_4 "#ebddcb"
              background "#1F1F99"
          }
          list_selected {
              base "#ebae34"
              emphasis_1 "#ebcc66"
              emphasis_2 "#fcdd77"
              emphasis_3 "#fddd99"
              emphasis_4 "#ffffff"
              background "#353830"
          }
          frame_unselected {
              base "#DCD8DD"
              emphasis_1 "#7FB4CA"
              emphasis_2 "#A3D4D5"
              emphasis_3 "#7AA89F"
              emphasis_4 "#DCD819"
          }
          frame_selected {
              base "#76946A"
              emphasis_1 "#C34043"
              emphasis_2 "#C8C093"
              emphasis_3 "#ACD7CD"
              emphasis_4 "#DCD819"
          }
          frame_highlight {
              base "#DCD819"
              emphasis_1 "#DCD819"
              emphasis_2 "#DCD819"
              emphasis_3 "#DCD819"
              emphasis_4 "#DCD819"
          }
          exit_code_success {
              base "#76946A"
              emphasis_1 "#A3D5D5"
              emphasis_2 "#76946A"
              emphasis_3 "#76946A"
              emphasis_4 "#76946A"
          }
          exit_code_error {
              base "#C34043"
              emphasis_1 "#DCD819"
              emphasis_2 "#C34043"
              emphasis_3 "#C34043"
              emphasis_4  "#C34043"
          }
          multiplayer_user_colors {
              player_1 "#C34043"
              player_2 "#C34043"
              player_3 "#C34043"
              player_4 "#C34043"
              player_5 "#C34043"
              player_6 "#C34043"
              player_7 "#C34043"
              player_8 "#C34043"
              player_9 "#C34043"
              player_10 "#C34043"
          }
    }
  }
}

[imsnif]

Hey @DeaconDesperado - thanks! Great work on this, I'm really stoked to see this taking shape. Here's another round of review (tested with the default theme but this is also present in the test-theme):

1. The Text elements seem to have lost their boldness in some cases (some examples I've seen: the Ctrl g in the status-bar in the "unlock-first" preset and the help text in the configuration screen (Ctrl o + c by default))
2. The non-colored elements in the configuration have turned gray rather than the original white
3. When the elements in the configuration "Change mode behavior" screen are selected, their colors are inverted to green for non-colored and red for the emphases
4. In general (continuing with point 3) I think the emphasis colors in selected elements (nested list and text) are off (no color gets us green, I think?)
5. The selected background does not appear for nested lists (eg. in the configuration "change mode behavior" screen)

In general - this PR has driven home the point for me that deciding to opt-out of tests for styling in Zellij was a mistake on my part! Unfortunately though, not one that can be easily fixed for the time being though. So I guess we're going to have to do some old-style eyeball comparison between the old and new UI elements to make sure nothing changed. Thankfully, the default plugins (session-manager - Ctrl o + w, plugin-manager - Ctrl o + p, configuration Ctrl o + c, welcome-screen zellij -l welcome, and the status-bar/tab-bar) use most if not all permutations of these plugins.

That being said, I'm happy to help with the side-by-side comparisons as I did here above since I know these interfaces quite well and know where to look.

[DeaconDesperado]

@imsnif

So I guess we're going to have to do some old-style eyeball comparison between the old and new UI elements to make sure nothing changed.

This is the method I have been using for the most part, swapping theme configurations between terminal windows and doing eyeball comparisons.

That being said, I'm happy to help with the side-by-side comparisons as I did here above since I know these interfaces quite well and know where to look.

I'm extremely grateful for your help with that... I doubt that I have enough personal familiarity with all of Zellij's different features to have a good sense of when something's off in all the various views. Case in point, issues 3 and 4 above were easily identifiable by looking at that configuration pane of the session mode, which was new to me at least 😄

The latest push above is rebased on main and includes fixes for all the stuff from the list.

[jokeyrhyme]

I wonder if we can identify pairs of elements that are expected to have good contrast, e.g. text on background

And have unit tests that assert that contrast is sufficient? For every included theme?

I wouldn't expect identification of 100% of such pairs, and I'd expect the definition of contrast would need to be quite generous to start with in order to not complain about existing themes

Just an initial framework with some obvious cases would be a great start