Idiomatic use of StyleManager from libadwaita

[ruifengx]

I see in the official demo of libadwaita a "theme switch" button (switching between light and dark variant) which I presume involves calling StyleMan::set_color_scheme upon clicked. I tried to replicate this behaviour using the relm4::widget macro, and had some problems.

I first tried to implement this manually (i.e., without the widget macro). I include a theme_variant field in my Model, and save a copy of the StyleManager as a style_man field, so in init_view:

let style_man = adw::StyleManager::for_display(&window.display());
style_man.set_color_scheme(model.theme_variant.to_color_scheme());

and also keep a copy of the theme switch button:

let theme_switch_button = gtk::Button::from_icon_name(icon_name);
theme_switch_button.connect_clicked(move |_| send!(sender, AppMsg::FlipTheme));

and for completeness, here's the definition of the ThemeVariant enum:

(collapsed by default to save space)

#[derive(Debug, Copy, Clone, Eq, PartialEq)]
pub enum ThemeVariant {
    Light,
    Dark,
}

impl ThemeVariant {
    fn inverse(&mut self) {
        *self = match *self {
            ThemeVariant::Light => ThemeVariant::Dark,
            ThemeVariant::Dark => ThemeVariant::Light,
        }
    }

    fn to_icon_name(self) -> &'static str {
        match self {
            ThemeVariant::Light => "light-mode-symbolic",
            ThemeVariant::Dark => "dark-mode-symbolic",
        }
    }

    fn to_color_scheme(self) -> adw::ColorScheme {
        match self {
            ThemeVariant::Light => adw::ColorScheme::PreferLight,
            ThemeVariant::Dark => adw::ColorScheme::PreferDark,
        }
    }
}

I then handle the Msg::FlipTheme message in the update function. So far so good.

---

However, if I use the widget macro, I have no where to put the style_man field. I can include that in the additional_fields! { ... } part, but it seems I would have to write the init/update logic manually, which clutters the implementation. Is there anything I missed here? I thought of putting the style_man in the model, but it requires being initialised from a Display, which I presume it is not a good idea to happen before RelmApp::run. I also thought of implementing the theme switch button as a standalone component (thus perhaps factor out the unidiomatic part), but I am not sure how much that would help in general.

P.S. It would be great if initialisation and track!(...) expressions were allowed in additional_fields! { ... }.

---

Edit: I managed to factor out the "theme switch" button into a component, and the code indeed looked better. However, I still want to hear someone else's opinion on this topic: generally how should we handle stateful elements outside the widget tree?

[AaronErhardt]

Have you tried pre_init or post_init? That's were you usually do the initialization for things that aren't widgets. Also, you can use trackers without the track! macro. But of course let me know if you have a good idea for improving the syntax.

[ruifengx]

Sorry, I should have made myself clearer. Yes, I tried the pre_init/post_init hooks, they work as intended. And yes, in post_view I am using the changed method of the tracker without the track! macro, and it also works as intended. But with all these hooks the code looks no longer as elegant as the one with only the view! { ... } block, and sadly it seems a normal impl block would look more consistent. I was in fact asking about whether or not we can make non-widget properties also somewhat "reactive", that is something like:

view! {
    window = adw::ApplicationWindow { ... },
    style_man = adw::StyleManager::for_display(window.display()) {
        set_color_scheme: track! { &model.theme_variant.to_color_scheme() },
    },
}

So basically this style_man field appears outside the main widget tree, but using the very same syntax. During codegen it should be attached to the Widgets struct as a normal field (and the root widget is the first one among all the top level entities in the view! { ... } block). In this way the whole logic is made declarative, instead of procedural.

My main concern is to group relevant things together, so all logic about the same element should appear at the same place: the initialisation and the update. In case a track! { ... } is not enough, I would suggest the following syntax:

view! {
    // ...
    thing: Type = manual! {
        init: the_initialisation_expr_here,
        update: the_update_expr_here,
    },
}

(Or maybe you can come up with better syntax.)

[AaronErhardt]

Very good idea! And the timing couldn't be better, I will add this to this newly created issue: #162
I don't think I will backport this feature but it should make it in the upcoming 0.5 release.