-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Theming Revolutions #2350
Theming Revolutions #2350
Conversation
Hey there. This is looking really good for creating custom widgets. We'll be able to use the widget classes like before instead of a function for each variant which I like. I have just one thing that I feel that lost some customization potential, which is the widgets with widgets in it, like the pick_list and combo_box. Previously we could set the default style for the pick_list field and the menu, we could also set the default style for a combo_box text_input and menu. |
@alex-ds13 I think you missed these methods. |
I saw them, but to use those it has to be on the view function. The idea would be that one could simply create a pick_list or combo_box while having a CustomTheme set on the Program and the default looks would be set already. This would allow creating a CustomTheme crate and anyone who wants to use it just sets that crate Theme as the Theme of the Program. And the view logic would stay this same. With those methods the user would have to do something like: use custom_theme::Theme;
pick_list(Theme::ALL, Some(self.theme), Message::ChangeTheme)
.menu_class(Theme::Menu::PickList) Wouldn't it be possible to have the /// The appearance of a pick list.
#[derive(Debug, Clone, Copy)]
pub struct Style {
/// The text [`Color`] of the pick list.
pub text_color: Color,
/// The placeholder [`Color`] of the pick list.
pub placeholder_color: Color,
/// The handle [`Color`] of the pick list.
pub handle_color: Color,
/// The [`Background`] of the pick list.
pub background: Background,
/// The [`Border`] of the pick list.
pub border: Border,
/// The [`Menu`] style of the pick list.
pub menu_style: menu::Style,
} And then the /// The default style of the field of a [`PickList`].
pub fn default(theme: &Theme, status: Status) -> Style {
let palette = theme.extended_palette();
let active = Style {
text_color: palette.background.weak.text,
background: palette.background.weak.color.into(),
placeholder_color: palette.background.strong.color,
handle_color: palette.background.weak.text,
border: Border {
radius: 2.0.into(),
width: 1.0,
color: palette.background.strong.color,
},
menu_style: menu::default(theme),
};
match status {
// ...
} |
@alex-ds13 74373cb should address that use case. |
Hey! It's me changing theming completely once again!
Well, not really. There should not be any breaking changes for users of the built-in theme—except just the rename of
Appearance
structs to simplyStyle
.The main change here lets custom theme implementors define a
Class
associated type that the widget will carry. ThisClass
is found in theDefaultStyle
trait, which has been renamed toCatalog
.This lets custom theme users control the styling of a widget completely—allocations included!
The
style
method of widgets is still readable:And, as you can see, as long as the
Class
associated type implementsFrom<StyleFn>
; widgets will be able to leverage the "closure styling" approach introduced in #2312.StyleFn
is just a type alias that every widget defines and is, as you'd expect, just a boxed style function:Finally, the widgets also expose a new
class
method:Which can be used to set the particular
Class
of the widget directly and, since all of this is for custom theme users only, it's gated under theadvanced
feature.