You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Most applications need to perform work in the background, without freezing the UI while they work. The current architecture can be easily extended to achieve this.
We can let users return an asynchronous action (i.e. a future) producing a Message in Application::update. The runtime will spawn each returned action in a thread pool and, once it finishes, feed the produced message back to update. This is also how Elm does it.
When it comes to implementing this, winit already supports user-specific events that can be sent from another thread. Accommodating iced_winit for this functionality should not be too complicated.
Here is an example of how the end-user API could look:
Most applications need to perform work in the background, without freezing the UI while they work. The current architecture can be easily extended to achieve this.
We can let users return an asynchronous action (i.e. a future) producing a
Message
inApplication::update
. The runtime will spawn each returned action in a thread pool and, once it finishes, feed the produced message back toupdate
. This is also how Elm does it.When it comes to implementing this,
winit
already supports user-specific events that can be sent from another thread. Accommodatingiced_winit
for this functionality should not be too complicated.Here is an example of how the end-user API could look:
The text was updated successfully, but these errors were encountered: