Lifecycle API: rebuilding the View/Widget tree

[ignatz]

Hi floemers,

I was looking for the means to rebuild the contents contents of an entire window or the entire application. Looking through the APIs I noticed that:

• most of the "inject event" apis are crate private but even than I couldn't find an appropriate lifecycle event
• that the view_fn view builder is of type FnOnce, so rebuilding the view is probably out of the question.
• and the only widget building I could find is the call to view.build() in WindowHandle::new.

So, I was wondering if it would be possible to get or add a hook for either:

• rebinding an existing window to a new view (I can already close a window and open a new one)
• or an accessible lifecycle event for rebuilding the widget tree

?

For context, I'm trying to build hot reload/restart capabilities.

Thanks!

[dzhou121]

The easiest way is probably to use dyn_container at the root. Then you can swap what's inside the dyn_container as you like.

[dzhou121]

This is a very interesting subject. I've been thinking about how or is it even possible to do hot reloading in Floem.

It's kind of no difference in hot reload from a different language or hot reload from your IDE, because it's going to be cross process communications anyways.

I don't know how you instruct Floem to build the view tree from the scripting language (it's super cool by the way), but do you think it's possible to have some sort of diffing of the view tree locally from the scripting language, and then instead of swapping everything out from the root view, but actually swapping only the changing ones?

[ignatz]

Glad to hear you're interested. Much appreciated.

It's kind of no difference in hot reload from a different language or hot reload from your IDE, because it's going to be cross process communications anyways.

You're probably thinking about how to trigger the hot reload. Agreed, there's some external signal whether it's a file watcher or a button in an IDE, all the same. FWIW, I was more talking about passing state across language boundaries and across lexicographical scopes when the UI is described in a different language. For this part at least, there are no process boundaries.

I don't know how you instruct Floem to build the view tree from the scripting language (it's super cool by the way)

I kept it straight forward by simply wrapping construction/destruction of widgets and views. Imagine a C-API like:

Widget* new_floem_text(const char* text);
void destroy_widget(Widget*);

but do you think it's possible to have some sort of diffing of the view tree locally from the scripting language, and then instead of swapping everything out from the root view, but actually swapping only the changing ones?

That's an interesting idea. I guess that would be quite hard to do, since I don't really know how a change to file x line y maps to the widget tree. It could affect one, all, or none.

I ended up trying something utterly simple, which sees to work alright for now... I added an optional argument for providing an explicit "key". For signals with keys, I'm keeping a copy of the state around and when reconstructing the view, including the signals, I inject the persisted state rather than the initial state. It's easy because it didn't require any changes to floem but one could imagine lowering this approach into floem if you folks were thinking about experimenting with e.g. hot reloadable shared objects.

I'm happy to share the work once things get into a better state. In any case, I can't thank you enough @dzhou121 , interacting has been a real treat 🙏

[dzhou121]

I think your approach to persist the state is actually a very clean way, since for a declarative UI, you would expect the same state would result in the same view tree.

It's definitely something we want to bring into Floem, which will be useful for your use case (it's going to be powerful if you can bind Floem to Python or any other scripting languages). Hot reload can probably be implemented in this way. And now thinking about it, the idea "same state result in the same view tree" can shape how you can do UI testing in Floem.

Thank you @ignatz for your work and I would look forward to seeing it.

[ignatz]

It's very basic but I hope it gets the idea across:

Screencast.from.2024-05-04.19-41-22.webm

EDIT:

And now thinking about it, the idea "same state result in the same view tree" can shape how you can do UI testing in Floem.

Hadn't thought that far but that's a great point.

[dzhou121]

That is utterly cool. Thanks for exploring it and sharing it!

I'll see if I can bring it into Floem after my ECS PR.

[ignatz]

@dzhou121 that's awesome, this gets me 90% there. I was able to add a button to the UI to rebuild the entire widget tree.

Do you have a suggestion for me on how to drive it externally? Signals under the hood deep on the thread-local RUNTIME, so I cannot simply pass it to a different thread and Application::run takes over the main thread for running the render loop. Is there either:

• a way for me to periodically poll a buffered channel on the UI thread, e.g. register a callback that gets called for every frame or periodic timer intervals?
• or is there a signal implementation where at least the writer-end can be sent to a different thread?

Thanks!

[dzhou121]

Yes, that would be create_ext_action

https://docs.rs/floem/latest/floem/ext_event/fn.create_ext_action.html

[dzhou121]

Or create_signal_from_channel

https://docs.rs/floem/latest/floem/ext_event/fn.create_signal_from_channel.html

[ignatz]

Awesome. That did the trick 🙇‍♀️