feat(plugins): add configurable black background for ui components

[dj95]

In #3658 (comment) we've discovered, that terminals handle transparency different (even with different platforms like linux and macOS!).

Thus it would be good to give plugin maintainers the ability to retain at least the transparent background in their plugins. In order to implement this, I've made one small addition to the line protocol, but very carefully to retain backwards compatibility.

Demo

---

Transparent

If a utf-8 separated byte list begins with a clear-text z, it will be considered "transparent". Eg.

<ESC>Pzribbon;z114,105,98,98,111,110,32,49<ESC>\

---

I've just implemented it to the Text and NestedListItem for now as a kind of proof-of-concept. In case you agree with this small addition, I can implement the flag also to the remaining components.

Please feel also free to close this pull request, in case you do not agree to this solution. I can also understand if you don't want to make changes to the protocol :)

[imsnif]

Hey, thanks for whipping this up! Let's leave this on the back burner for now as an alternative. We might want to add explicit background colors to UI components in the future and since this is a protocol, it would be better to give it some more thought.

I'd rather solve this issue in its core if possible. My current thinking is to revert the background color PR and then fix things by removing the background color of the status-bar and tab-bar entirely. Assuming we can find a way to get the ribbons to look natural without a background (not sure if this is possible). Would you like to give that a shot?

[dj95]

No worries. Defining the background color would also be a cool use case. Especially when you then can omit it to create transparency.

For the latter one, I'm not sure if it's possible. After some research in various terminals and issue trackers, it does not seem to be possible in a consistent way. The only solution I could find is the current behaviour of zellij with specific terminals (kitty, alacritty, rio), but not for all of them.

Another solution would be to have a feature toggle for specific terminals to fix the transparent behaviour for powerline, such that you can toggle the commit you want to revert. But I'm not sure if it will be too hard to maintain or too confusing.

---

For alacritty, I found out that you need to configure the behaviour. It's now also added to the table of the previous discussion.

[imsnif]

Alright, thanks for looking into this. Personally I'm not a fan of having this be configurable. This feels to me like one of those "offloading complexity on to the user" sort of things. IMO we should find the "right" way to behave. I'm leaning toward reverting the commit and then specifying in the docs that a theme's "black" color should also be the terminal background (until the theme overhaul PR is merged and then things will be much clearer). I want to give this some more thought though - maybe I'll come up with something else (or you'll have another idea).

[imsnif]

Hey @dj95 - I thought about this some more and decided to go with this direction after all with a minor change (see below).

My rationale: the best way would be to "do the right thing" and have all UI components use the terminal's background and be transparent if the terminal is transparent (which Zellij cannot know about). Since this is not possible (as you discovered in the linked issue), I think the second best thing would be to have plugin authors deal with this issue. They know best whether their component should have a background (eg. when dealing with bars) or should defer to the terminal's background (eg. when representing text, titles, items in lists, etc.)

I feel though that the basic use-case should be deferring to the terminal's background, with an explicit "theme's black" background being the exception. So I'd like to go forward with this change but reverse the config flag. What do you think, would you like to adjust this PR? (also, full disclaimer: I have not looked at the code for this, so might have more comments once this is changed).

[dj95]

Hi @imsnif, sure. I can go forward with it.

So you mean, that there's not a .transparent() function for text, but some sort of .bg_black()? I think that's a good addition, as it does not break the current functionality and plugin API.

Also, feel free to review it afterwards, I'm completely open for any feedback :)

[dj95]

The flag is now implemented for text, nested lists and tables. I've also added a precedence, such that the selected() flag has a higher priority, than .bg_black().

However, I'm not sure what to do with the ribbons. I've tried several things there. We could set the transparent background on the ending symbol, but not as foreground on the first symbol. But that looks a little bit inconsistent and would break current behaviour.

Here's a test screenshot of the current state:

[imsnif]

Hey @dj95 - thanks for putting this together!

A few points:

1. Instead of bg_black, let's call it opaque. We might want to add background parsing in the future and since this is a protocol we'll need to still have it make sense :)
2. The precedence with selected is great - nice touch! Can we do it on the server side too so the API isn't solely in-charge of it? (I think it's that way in most places but not all)
3. About ribbons: I don't think we have anything to do here. Let's have them be opaque and leave it at that.
4. Would you like to move the built-in components to use this new API? I think this will fix a lot of problems in some themes. The guideline is: if it's in a bar (eg. tab-bar or status-bar) it should be opaque, otherwise it should be transparent. Ribbons should ideally color the rest of the line to be a black-background bar (this should be done with ANSI from within the plugin, I think the status-bar does this... something like \033[46mI am a ribbon\033[K. You can test this out in your terminal with: echo -e "\033[46mI am a ribbon\033[K"

Let me know if you want more specific pointers (especially regarding 4), I can look up specific places in the code where this is done.

[dj95]

Thanks a lot for your feedback. I've tried to implement it everything.

1. renamed bg_black() to opaque (which I really like!)
2. precedence handling is now also implemented in the server. The only thing there is, that selected and opaque needs to be received in the correct order, as it's a line protocol. I can also try to implement the for various combinations, if you'd like to (zx and xz; right now only xz will work correctly).
3. Left them, as they are
4. Implemented the change in the tab-bar, session-manager and plugin-manager. status-bar and compact-bar seem to already have the completely opaque bar implemented. Strider does not have any status bars or ribbons, if I saw it correctly.

[imsnif]

Hey, great work!

I played around with it and have some additions ( I test these by setting the theme's black color to something distinct from my terminal background, so everything looks horrible - sorry). I don't remember if these are implemented as UI components or self rolled, if it's the latter we can forgo them (though if you'd like to do them anyway, that'd be awesome - but it can be a lot of work)

1. The new "one-line ui", we need to have the primary and secondary modifiers have a black background (first screenshot) and also the mode shortcuts (second screenshot)
   
   
   

2. The tab bar in the configuration:
   
   

Otherwise, about the protocol - let's enforce explicit order. I'll make sure to document it.

[dj95]

Hey,

one-line UI and configuration plugin are now fixed. I've also rebased the MR on the new main changes.

[imsnif]

Fantastic (and quick!) job. Thank you!