Runtime theme switching: swap DefaultProperties without a restart

[mark-ik]

Hi,

I'm a hobbyist making a music practice app using Xilem, among other things. I have an issue with swapping themes at runtime; the widgets and buttons and whatnot only update at init time, so you have to restart (no bueno!).

screencap of the problem in my app

(Old screenshot, but pictured: a music practice app's settings page. The buttons remain black from the dark theme when I switch to the light theme, which is not the intended behavior.)

I wanted to ask whether I should submit a pull request with a fix. masonry's render_root.rs even carries a // TODO: Find better ways to customize default property set.

I don't want to step on any toes though, so let me be up front in saying I use AI. It's all tools to me, and I couldn't find any AI policy, but no hard feelings if y'all don't want submissions of this nature.

screencap of the problem fixed in my app

(Pictured: a music practice app's settings page, with more options reflecting additional development. There are more theme presets and configurable primary/secondary/tertiary/neutral colors, and switching themes changes the buttons to the correct color palette because the fix is in this build)

the fix (two small additions)

masonry_core: RenderRoot gains a runtime setter:

// Replace the tree-wide default properties at runtime and repaint.
pub fn set_default_properties(&mut self, default_properties: Arc<DefaultProperties>) {
    self.property_arena.default_properties = default_properties;
    self.request_render_all();
}

xilem: WindowView takes them reactively, applied only when the Arc identity changes (so steady-state frames don't re-apply):

pub fn with_default_properties(mut self, props: Arc<DefaultProperties>) -> Self { ... }
// in rebuild(): if the Arc changed, window.render_root().set_default_properties(props.clone());

This is just swapping at runtime, not the broader set of changes required for per-widget TextInput::background_color or more granular configuration. But I've run it for weeks, seems to work fine. Apologies if I've made mistakes in this issue, I never really do this >_<

Relevant issues:

#1765
#1786

[PoignardAzur]

Thanks for opening this issue, and for exploring potential solutions! You haven't made any shocking mistake.

I don't want to step on any toes though, so let me be up front in saying I use AI. It's all tools to me, and I couldn't find any AI policy, but no hard feelings if y'all don't want submissions of this nature.

We're in the middle of publishing one. The short version is it's mostly fine is you disclose it ahead of time.

the fix (two small additions)

self.request_render_all(); probably isn't powerful enough. Changing properties can trigger arbitrary code. Not sure what the best way to proceed would be. Since changing the entire property set would be relatively rare, you might want to iterate over the entire widget tree and call on_property_changed for every single cached property.

If you do open a PR, I'd recommend starting with the Masonry fix first, and doing the Xilem fix in a separate PR.

[mark-ik]

Ahh, my original fix worked by fluke. A label's ContentColor cache gets written lazily on any property read via resolve_cached_mut. What's cached is the index, not the value: for ContentColor that index resolves to "use the default," so the value was read fresh from the (now updated) default_properties. That recolors on a plain repaint, but it skips property_changed, which is where widgets would react to a change, right?

So the order should be updating the properties, iterating over the tree, setting the update flags, invalidating each cache, and then repainting once that's done? That triggers the update pass to re-fire property_changed for every cached property, so widgets can react as they should and the framework requests the right passes (a relayout for a size-affecting prop, say). self.request_render_all(); then runs with those requests in place and reads the new default properties.

// (1) update the default properties
// (2) flag every node for the pass + invalidate its cache 
// (3) repaint
pub fn set_default_properties(&mut self, default_properties: Arc<DefaultProperties>) {
    self.property_arena.default_properties = default_properties;  // swap first

    fn invalidate_props_all_in(node: ArenaMut<'_, WidgetArenaNode>) {
        let state = &mut node.item.state;
        state.request_update_props = true;        // enter the cache-eviction branch
        state.needs_update_props = true;          // flag so the pass descends to this node
        state.property_cache.invalidated = true;  // trigger the per-entry re-fire
        // ...recursion over widget tree...
    }
    let root_node = self.widget_arena.get_node_mut(self.root_id());
    invalidate_props_all_in(root_node);

    self.request_render_all();                    // paint last
}

I think that works, does the ordering look right?

[PoignardAzur]

You don't need request_render_all, but otherwise, sounds about right.

[mark-ik]

Ok, because the widgets themselves will do it (ContentColor::prop_changed calls ctx.request_paint_only(), etc.), got it

[mark-ik]

Ah, here's the PR that will close this issue:

#1822

[PoignardAzur]

Thanks, but Github already gives you that info. Just above your comment, there's a notification that says:

mark-ik linked a pull request that will close this issue last week

xilem: WindowView::with_default_properties for runtime theme swap#1822