I3status-rust: [Low Prio] New Themes

[greshake]

We should have more themes than solarized-dark, especially a simple text/i3status style one. To add them, just edit the src/themes.rs file. It should be obvious how to add a new theme. Every theme is Json, containing foreground and background colors for each block state (Warning, Info, Critical etc). Also here you can define the separator symbol.

[hansondr]

Plans to support custom themes directly in the TOML without overriding an internal theme?

currently:

[theme]
name = "solarized-dark"
[theme.overrides]
idle_bg = "#123456"
idle_fg = "#abcdef"
# ...

perhaps something like the following:

[[theme]]
idle_bg = "#123456"
idle_fg = "#afcdef"
# ...

[greshake]

Not really. You can select 'plain' as your base theme, but I mean it doesn't matter if you specify/override all the attributes, you got yourself a new theme. I want to encourage people to publish their themes in a PR, not sure if this does, but at worst it's a semantic oddity without functional impairment.

[MarcelPa]

Just to pitch an idea: the terminal colors from Xresources could be used as a theme. This would enable selecting themes from sites like xcolors.net or similar.
I would be willing to implement this, but I am still in a process of learning Rust. Basically, this should "only" involve parsing the Xresources file and getting all RGBA values needed; not the hardest problem I guess.
Any thoughts on this?

[greshake]

Parsing the Xresources won't be a problem... Converting it into a i3status-rust theme won't be either. Ideally, we want to allow for specifiying a path (to an Xresources file) as the theme parameter. Easiest way to imlement is in the theme.rs file, there is a function mapping a theme name to a theme instance. We simply need to distinguish paths and known theme names and try to generate a theme instance for paths on the fly. Should be quite easy. Just see if there is a theme with the string as name available and, if not, try to treat it as an Xresources file.

[lausek]

I really dislike the idea of having another configuration file just for colors. @hansondr idea sounds great for me. We could utilize the [theme] section inside the status config for setting colors and everything else.

So, I think we should remove all hardcoded themes except PLAIN. In my opinion, the following would be a good order for applying styles:

1. Read Xresources of user - typically at ~/.Xresources
2. Read the attributes specified under [theme] inside the configuration file and override attributes placed by the previous step
3. Everything else should be taken from the PLAIN template

Of course, this is a breaking change.

[atheriel]

I'll chime in here.

First, I know that several users (including myself) are running under Wayland, so we don't want to default to reading .Xresources, especially first. I'd rather have a use_xresources parameter defaulting to false in the [theme] section. Making this opt-in would also be backwards-compatible.

Second, I like the idea of having separate theme files -- which is exactly what supporting .Xresources amounts to, but with the additional baggage of depending on X. A separate theme file would also allow popular tools like wal or pywal to procedurally generate colour schemes for us, something that is currently impossible (because you can't fragment the configuration).

Third, I think that we should keep theme.overrides, because I think in all three cases (default theme, theme file, and .Xresources) it would be nice to override very specific elements.

What I am proposing is that we allow three mutually-exclusive top-level directives in the [theme] section:

• name (which is backwards-compatible and names a built-in theme);
• file, the path to a complete theme file, in TOML format; and
• use_xresources, which will read in that file when true.

For example, to use one of the built-in themes,

[theme]
name = "solarized-dark"
# file = 
# use_xresources = false

[theme.overrides]
idle_bg = "#123456"

And to use .Xresources:

[theme]
use_xresources = true

[theme.overrides]
idle_bg = "#123456"

And to use a custom theme file:

[theme]
file = "path/to/theme.toml"
# use_xresources = false
# name = "plain"

[theme.overrides]
idle_bg = "#123456"

As an implementation detail, once we had themes reading from TOML files we could then refactor the current hard-coded themes into separate theme files and include them during the installation (likely somewhere in /etc). Then the name parameter would simple read a file from the theme directory, allowing users to "install" additional themes from the community.

All of this is, I believe, backwards-compatible. Does this make sense to others?