theming suggestions #49

Closed
opened 2020-04-04 19:24:23 +03:00 by cycomanic · 6 comments

I'm just trying to create a theme that fits my use-case. And I noticed two things that would be nice to have. Not sure how easy they are to implement.

  1. It would be cool if it was possible to have italic text.

  2. One issue I encountered the compact list view is, the ability to theme odd/even is very nice. However if there is a lot of unseen messages in the same view, the odd/even distinction is gone. It would be great if one could only specify a single attribute, i.e. bold font, and it would automatically inherit from what the view was before. So if I for example make the background white for odd and black for even, and then unseen messages I make bold. The backgrounds would all still alternate between black/white even for the unseen messages.

I'm just trying to create a theme that fits my use-case. And I noticed two things that would be nice to have. Not sure how easy they are to implement. 1. It would be cool if it was possible to have italic text. 2. One issue I encountered the compact list view is, the ability to theme odd/even is very nice. However if there is a lot of unseen messages in the same view, the odd/even distinction is gone. It would be great if one could only specify a single attribute, i.e. bold font, and it would automatically inherit from what the view was before. So if I for example make the background white for odd and black for even, and then unseen messages I make bold. The backgrounds would all still alternate between black/white even for the unseen messages.

These are good suggestions!

It would be cool if it was possible to have italic text.

While at it, there should also be dimmed, blink and hidden text. These are all in the xterm escape code sequences but may not be supported in all terminals.

o if I for example make the background white for odd and black for even, and then unseen messages I make bold. The backgrounds would all still alternate between black/white even for the unseen messages.

The problem with this is that there's no distinction for a user-set value vs app-default in themes, so there's no way to know if for example the unseen even background should default to even background unless user has set the unseen even background value.

Instead the following is cleaner and easy to implement: Have separate theme keys for even unseen, odd unseen, even highlighted, etc. It's a bit verbose put provides more flexibility for custom themes.

These are good suggestions! > It would be cool if it was possible to have italic text. While at it, there should also be dimmed, blink and hidden text. These are all in the xterm escape code sequences but may not be supported in all terminals. > o if I for example make the background white for odd and black for even, and then unseen messages I make bold. The backgrounds would all still alternate between black/white even for the unseen messages. The problem with this is that there's no distinction for a user-set value vs app-default in themes, so there's no way to know if for example the unseen even background should default to even background unless user has set the unseen even background value. Instead the following is cleaner and easy to implement: Have separate theme keys for `even unseen`, `odd unseen`, `even highlighted`, etc. It's a bit verbose put provides more flexibility for custom themes.
Manos Pitsidianakis added the
enhancement
label 2020-04-05 14:46:54 +03:00

Here's a preview

Here's a preview

The problem with this is that there's no distinction for a user-set value vs app-default in themes, so there's no way to know if for example the unseen even background should default to even background unless user has set the unseen even background value.

Ok I understand. Maybe the option to avoid the verbosity is to have a keyword parent? And then make a bit more hierachy, i.e. have list.odd.unseen , list.even.unseen, list.even.selected ... if one would then set list.odd.unseen = {fg="parent", bg="white"} it takes the foreground value from the parent, i.e. list.odd?

Obviously what you did works as well I'm just thinking about a way to avoid having to repeat a lot of values.

> The problem with this is that there's no distinction for a user-set value vs app-default in themes, so there's no way to know if for example the unseen even background should default to even background unless user has set the unseen even background value. Ok I understand. Maybe the option to avoid the verbosity is to have a keyword parent? And then make a bit more hierachy, i.e. have list.odd.unseen , list.even.unseen, list.even.selected ... if one would then set list.odd.unseen = {fg="parent", bg="white"} it takes the foreground value from the parent, i.e. list.odd? Obviously what you did works as well I'm just thinking about a way to avoid having to repeat a lot of values.

I think this is essentially the same thing but with different key names, isn't it?

I think this is essentially the same thing but with different key names, isn't it?

Actually, you're right it does not make a difference, because it does not really matter if you put in a color or the "parent" keyword. It would be nice to be able to define custom color names though, that way it's easier to reuse colors, without making mistakes.

Actually, you're right it does not make a difference, because it does not really matter if you put in a color or the "parent" keyword. It would be nice to be able to define custom color names though, that way it's easier to reuse colors, without making mistakes.

That'd be useful indeed. TOML doesn't allow variables though so this would require some non-trivial rewrite, unless it can become a m4 macro and expand the colour names in preprocess. I'll look into it.

That'd be useful indeed. TOML doesn't allow variables though so this would require some non-trivial rewrite, unless it can become a m4 macro and expand the colour names in preprocess. I'll look into it.
Sign in to join this conversation.
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: meli/meli#49
There is no content yet.