When I close the window on MacOS,
Since the current version of winit::event_loop seems to be causing a panic without returning control flow,
Drop traits for variables allocated by the my application are not executed.
I want something like this,
Is it better to cast a window event and handle it immediately?
Since the current version of winit::event_loop seems to be causing a panic without returning control flow,
This sounds like a winit issue. The application shouldn't panic once you close the window.
I want something like this
That's one way to approach it. However, closing applications gracefully is sometimes more complicated than that. Users may need to run commands and wait until completion, for instance.
Because of this, I think it's a good idea to differentiate between a close request and the application deciding it should exit. We could add a new event CloseRequested, which could in turn be captured by a Subscription, and a method Application::should_exit or similar, which can be used by the runtime to know when to finish the event loop.
Sounds good?
This sounds like a winit issue. The application shouldn't panic once you close the window.
Sorry for not being able to tell you exactly what happened.
That's right. I think this is a winit issue. No explicit panic message is displayed, but anyway, closing the window terminates the process immediately.
There are no bugs in iced for this issue.
Because of this, I think it's a good idea to differentiate between a close request and the application deciding it should exit. We could add a new event CloseRequested, which could in turn be captured by a Subscription, and a method Application::should_exit or similar, which can be used by the runtime to know when to finish the event loop.
I think it is very good.
Since the subscription argument is &self,
If you include &mut self as an argument of Application::should_exit, my wish will come true.
I hit this today, and am wondering if your suggestion is sufficiently non-controversial for me to implement. Specifically:
Because of this, I think it's a good idea to differentiate between a close request and the application deciding it should exit. We could add a new event
CloseRequested, which could in turn be captured by aSubscription, and a methodApplication::should_exitor similar, which can be used by the runtime to know when to finish the event loop.Sounds good?
Which I interpret as:
Converting ControlFlow::Exit into an event widgets/subscriptions can match on, maybe we can call the invariant iced_native::event::Event::Window::ExitPressed
Removing https://github.com/hecrj/iced/blob/d16b9cf7cd98a3d65ea5408ac9b72298cb267e85/winit/src/application.rs#L163-L165
Adding a new method to Application: fn should_exit(&self) -> bool' which aborts the event loop if true is returned
Most helpful comment
This sounds like a
winitissue. The application shouldn't panic once you close the window.That's one way to approach it. However, closing applications gracefully is sometimes more complicated than that. Users may need to run commands and wait until completion, for instance.
Because of this, I think it's a good idea to differentiate between a close request and the application deciding it should exit. We could add a new event
CloseRequested, which could in turn be captured by aSubscription, and a methodApplication::should_exitor similar, which can be used by the runtime to know when to finish the event loop.Sounds good?