Allow for themes

[coastalwhite]

Add a theme section to the configuration file that sets a number of general colors. Other configuration options should then be able to refer to these keys. At runtime, the configuration value will then get replaced by the color value specified in the theme.

An example user-configuration (config.toml) would be

[theme]
border = "white"
border-active = "orange"
# ...

The default configuration would then include:

# ...

[username_field.style]
border_color = "${theme.border}"
border_color_focused = "${theme.border_focused}"

[password_field.style]
border_color = "${theme.border}"
border_color_focused = "${theme.border_focused}"

The changes to the code would essentially all take place in config.rs.

theme.toml

Alternatively, a user could provide a theme.toml file in the /etc/lemurs directory. This would override any existing [theme] section within the config.toml. However, A warn! log could be thrown when there is both a theme.toml file and a [theme] section. This file can help with portability and easily changing themes through for example symlinks.

The theme file would be a toml file without headers.

border = "white"
border-active = "orange"
# ...

Notes

• Should the theme color values be able to mention other theme colors? This would create possible circular dependencies.
• Preparing for #71, it is probably wise to add a namespace to the theme variables (e.g. theme.key or theme::key).

[danielgafni]

Hey, I might be interested in working on this. What do you think?

[coastalwhite]

Hello Daniel,

That would be wonderful. I added a bit of what I envision this to be as the description of this issue. It essentially comes down to replacing some of the values after the configuration has been parsed. I guess that this should only require changing src/config.rs. If you have any questions, please let me know.

[danielgafni]

Do you think we should support a separate theme.toml file for easier themes management & sharing?

[coastalwhite]

That is actually a really good idea. I am not sure how we should incorporate #67 into this. For now, just having a theme.toml is great.

[danielgafni]

I'm thinking to introduce a new top-level struct: ConfigsCollection for this purpose.

The old top-level Config would be one of it's fields. Another field would be Theme.

Is this the right way to think about it?

[coastalwhite]

I think we could resolve this immediately when Config is created. This way the rest of the program doesn’t have to deal with the consequences of introducing a new layer of abstraction.

When, we load the configuration we load the theme as well and replace the corresponding configuration values immediately.

[danielgafni]

So you want to have the theme section in the main config and override it from a theme.toml file if it exists?

[coastalwhite]

I added a bit more detail to the main description.

Basically, the user can specify a [theme] section or have a theme.toml file in /etc/lemurs. If they are both present, use the theme.toml file. Probably also log a warn!.

[danielgafni]

Hey!

1. Which parameters do we want to include into theme.toml? For now I'm only including colors and modifiers.
2. Should we keep the old parameters? If so, what is the best place to replace their values from the new theme parameters? Is it main.rs right after config is created? As I understand, the new theme parameters should take preference over the old ones.

[coastalwhite]

Just colors and parameters is fine for now. I think we just have a general set of variables, and then the default configuration references those variables.

An example user-configuration (theme.toml) would be

border = "white"
border-active = "orange"
# ...

The default configuration would then include:

# ...

[username_field.style]
border_color = "${theme.border}"
border_color_focused = "${theme.border_focused}"

[password_field.style]
border_color = "${theme.border}"
border_color_focused = "${theme.border_focused}"

[danielgafni]

Where is the ${var} interpolation functionality you are describing coming from?

I don't think Serde has such a feature. Are you suggesting to implement it in config.rs or am I missing something?

I'm coming from Python and for example OmegaConf supports it, that's why I'm asking...

[coastalwhite]

No, we have to resolve the variables ourselves. The toml crate does not support it.