Theming

[hecrj]

This proposal introduces the first-class concept of a theme in iced. A theme is defined as some data type capable of changing the default look of the widgets of an application.

Rendered

[mmstick]

Would it be possible to change the theme on-demand, such as if the theme is loaded from a configuration file?

[hecrj]

@mmstick Yes. You could load your theme in Application::new with a Command (or in main and pass it as Flags) and then use a custom Subscription to listen to any changes to the configuration files.

[13r0ck]

An Autodetect variant could be added to the built-in Theme to let iced choose the best fitting variant of the Theme based on the environment (e.g. OS settings).

Would this just be at application init?

Is there any interest in having included helper functions to manage theme? Both in the theme function, and subscription, there will be a lot of edge cases that could be simplified for the developer. Because each OS (and on linux each DE 😬 ) is going to have to have its own way of listening to any combination of changes of light/dark change, accent color change, high contrast mode, etc

Should we introduce the Theme associated type to Sandbox too? Or should we hardcode the built-in Theme for any Sandbox application?

i think no, it would be nice to have auto-detect for system light/dark mode (but not necessary). commands are such a necessity for any production app that sandbox is mostly just for learning very basic concepts. I don't think sandbox should be complicated more

This may be a good change to rethink and improve the default styling for every widget. What kind of styling should we use for the Light and Dark variants of the built-in Theme?

I think the light/dark themes from the styling example are more than good enough for now 😄

I don't think in practice it would matter much, but currently the subscription function is run after update and before view, if I'm not mistaken? So would the order now be update->subscription->theme->view ?

Thank you for putting so much thought into this, looks great! ❤️

[hecrj]

@13r0ck

Would this just be at application init?

No. Ideally we should build this on top of a proper OS abstraction that can listen to configuration changes.

Is there any interest in having included helper functions to manage theme? Both in the theme function, and subscription, there will be a lot of edge cases that could be simplified for the developer. Because each OS (and on linux each DE 😬 ) is going to have to have its own way of listening to any combination of changes of light/dark change, accent color change, high contrast mode, etc

Ideally, we will eventually detect many OS settings (including different Linux DEs) in order to choose / change the active Theme, but it will be a long run until we get there.

The plan here is to introduce the foundations for allowing users to implement these features themselves as well as exposing them in a nice way! iced does not need to implement complex theming support natively in order for you to have it.

For instance, you could open-source a theming crate that exposes a new Theme and a custom subscription to keep it updated in a cross-platform way. You could go further and also expose your own Application trait with your new Theme and custom subscription already hardcoded, so anyone could quickly get started with it.

Then, in the long run, iced could consider adopting one of the existing approaches as the built-in theme strategy. But, in the meanwhile, iced won't be the bottleneck.

I think the light/dark themes from the styling example are more than good enough for now 😄

The dark theme there is mostly a copycat of the Discord color palette. Maybe we could change the background color a bit...

We should also probably discuss the different built-in variants that we want to have available for every widget.

sandbox is mostly just for learning very basic concepts. I don't think sandbox should be complicated more

Yeah, good point. I'm leaning towards that as well.

I don't think in practice it would matter much, but currently the subscription function is run after update and before view, if I'm not mistaken? So would the order now be update->subscription->theme->view ?

The ordering is irrelevant. If you are worried about Subscription changes propagating to Theme, there is nothing to be worried about. A custom theme Subscription should produce a Message when the Theme changes, which will trigger an update and a theme call after that.

Thank you for putting so much thought into this, looks great! ❤️

Glad you like it!

[13r0ck]

@hecrj
All of that sounds good to me!

The ordering is irrelevant. If you are worried about Subscription changes propagating to Theme, there is nothing to be worried about. A custom theme Subscription should produce a Message when the Theme changes, which will trigger an update and a theme call after that.

Oh no I wasn't worried about propagation issues, just mostly to have an answer when people ask on the discord 😄

[13r0ck]

We should also probably discuss the different built-in variants that we want to have available for every widget.

I think a reasonable starting point would be:

• Default
• Hover
• Focused
• Pressed
• Disabled

A future table widget could be rather complicated though, i would see all of those + alternating rows/columns + header column + divider, etc, but we don't have a table widget yet, so those details can wait

[hecrj]

@13r0ck Variants are not the possible states of a widget, but actually styling variations of the whole widget.

For instance a Button can be Primary, Secondary, Positive, Destructive, etc.

[13r0ck]

Oh 🤦

Um, I think gnome theming uses suggested destructive, and those are considered the "Primary" options, and then there is a secondary. It would also be nice to have a text option, as in iced buttons and hyperlink like buttons are the same thing.

Potentially another emphasis variant for when a group of buttons all have the same value to the user, but are different from standard buttons, like a "Shutdown"/"Cancel" buttons, where you don't want to suggest the user does one or the other, but you also want the buttons to be different so the user thinks about the action slightly more than a standard button/

Maybe containers should have a similar set of themes, beyond that I think most widgets will just have their states.

[emann]

First off, love love LOVE the variant stuff! I'm kinda confused as to how color schemes play into this though - the unresolved questions/future possibilities sections seem to imply that color scheme stuff would be related to variants? IMO, they should be separate.

Here's how I envision it to allow on the fly color scheme swapping goodness:

• A 'ColorPalette' defines strict bounds on the number of colors used and more importantly their identifiers. Examples would include specifying colors for active, accent, action, positive, background, etc.
• A 'Variant' defines the ways in which widgets/elements are shaped/rendered and selects colors from the ColorPalette to paint different parts of the widget (e.g. button border is MyCustomColorPalette.acent
• A Theme simply defines the Variant types for each widget as well as the ColorPalette type (which is applied to all widgets/variants/etc.). This decouples the shaping of elements from the ways in which they're colored but leaves their relationship/dependency intact, allowing the user to keep a consistent theme but change color palette instances (e.g. from light mode to dark mode) on the fly.

[hecrj]

@emann I believe my Theme is also your ColorPalette. I do not see the need to separate both concepts.

[emann]

@hecrj Surely that would create some redundancy then, no? If I want the widgets to all look the exact same in light mode and dark mode with the only difference being that dark mode uses black instead of white and say purple instead of a bright green, wouldn't that require some code duplication?

Perhaps different vocabulary may make my thinking clearer - I see the Theme as representing a design language/system (e.g. material design, windows native looking theming, macos native looking theming all being different design languages) and ColorPalette being just that - the colors used. The color palette may be as simple as different colors for light vs. dark but could also be dependent on system settings (I know in windows you can set a global color scheme for compatible apps to use, would be sick as hell to support that).

TLDR; I feel tightly coupling the way things are shaped/styled with the colors applied to them will cause a lot of duplication and potentially introduce some annoyance.

[hecrj]

@emann

wouldn't that require some code duplication?

I don't see why. You can create any internal abstractions to manage your supported color schemes. iced does not need to know about those internal details, however.

For instance, you could have:

pub enum Theme {
    Light,
    Dark,
}

struct Palette {
    base: Color,
    text: Color,
    // ...
}

impl Theme {
    fn palette(&self) -> Palette {
        // ...
    }
}

impl button::StyleSheet for Theme {
    type Variant = /* ... */;

    fn active(&self, variant: Self::Variant) -> button::Style {
        let palette = self.palette();

        // ...
    }
}

iced (and its users) only see and care about the Theme. There is no need for iced to dictate how the actual style sheets should be implemented. In other words, the idea of a Palette isn't necessary and, therefore, the design doesn't need to account for it.

[emann]

@hecrj Damn. Couldn't agree more when you put it that way haha. I do however think that maybe there could be some basic implementation of "A theme which has switchable color palettes" somewhere, along with things like a theme that automatically detects light vs dark mode and selects the appropriate color scheme. Presumably this stuff would live in a separate crate altogether (iced_theming_utils or something) with feature flagging for all the things.

[emann]

Also I think my second pass at implementing this stuff is fairly similar to what you described here, would love to help out with/lead aligning it with the RFC!

[hecrj]

@emann No worries. Code is the easy part! I already have a working implementation of the ideas presented here.

[oknozor]

Really exited to see this coming in iced!

As far as I understand you are not planning to tight theming to a specific configuration format and will leave the implementation to end users for now, which is fine I guess.

However reading at the rfc I am wondering if it would be possible to add some kind of css like selectors to widgets so we can override the theme in use for specific widget and define new styles that wouldn't be tight to any application code.

Motivation

The current rfc allow to change the global style of an application by defining a theme and introduce an associated type to add variants to a theme for a specific widget. But the example suggest that we would still need to hard code this variant associated types in our theme implementation :

button("Destructive").variant(theme::Button::Destructive)

This is definitely an improvement but ultimately, end user should be able to completely change the style of an iced application without having to write any application code (at least if the application chose to expose a theme configuration file).

A possible solution would be to introduce css like selectors. Note that I am not suggesting css should be used here, only that widget should bind to a selector name in the theme definition.

Example

Let's consider the following widget definition, and assume that I have implemented binding to a css like configuration file for the theme in use :

Container::new(Column::new()
  .push(search_bar)
  .push(scrollable))

First I would like to be able to use default selectors for iceds widgets :

container column {
  alignment: start; 
  width: fill; 
  padding: 20
}

And to use my own css like class selectors :

Container::new(Column::new()
  .push(search_bar)
  .push(scrollable)
  .class("centered"))

container column.centered {
  alignment: center; 
  width: fill; 
  padding: 10
}

Do you think the current rfc once implemented could be extended to this ?

[hecrj]

@oknozor

end user should be able to completely change the style of an iced application without having to write any application code

I don't see why. I don't think iced should be concerned about allowing this for every application. The current RFC allows developers to build their own custom, configurable themes.

Also, I really don't like the idea of cascading styles with selectors. I believe widgets should be explicitly styled in view logic, instead of implicitly by some separate rules and its context.

Finally, styling will never affect layout. This means that a Theme won't be able to affect properties like width, alignment, and padding directly.

[alex13sh]

Would it be possible to make a castom StyleSheet for a Button? without changing the styles of other widgets.
To do this, I need to make new Theme and implement StyleSheet for all widgets I use?
Or to do this, I need to make a wrapper over the Button?

There is an idea to add a castom variant of the boxed StyleSheet for all widgets in the standard theme.

[hecrj]

I have updated the RFC to reflect some of the decisions taken here and the latest explorations from my part.

I think we are very close to getting this merged. Let me know what you think!

[13r0ck]

Looks good to me! 🎉