`Window` component should have `destroying`/`being-destroyed` callback

[Enyium]

You should be able to run final .slint code, like taking data from the UI, before your app (or just window) is shut down. This is similar to #6401, but would allow to run code unconditionally, no matter whether the end user closed the window in question, or it was programmatically hidden and is subsequently being destroyed.

Maybe, this would require hide() to start behaving differently, namely to only destroy the internal strong reference in a closure enqueued in the event loop. This could be desirable anyways. Like with quit_event_loop() (see also #6562), it can be useful to enqueue actions in the event loop using invoke_from_event_loop(), and then call hide() and/or quit_event_loop(), without the window having been destroyed before the actions ran. This would make Slint's behavior much more predictable.

With the behavior as it currently is, you're required to jump through hoops (that I didn't figure out at the time of writing) to get .slint code to run before the window is destroyed on hide(), at least in certain app designs where your holding onto the component doesn't span the runs of the closures sent via invoke_from_event_loop(). With an app design utilizing RefCell, you can definitely not simply synchronously invoke_...() a .slint function that calls back to Rust, but need to wrap that in invoke_from_event_loop(), because you can get RefCell panics that way. But that execution will then be too late.

[ogoffart]

Could you elaborate a bit more the use case? Why is on_close_requested not sufficient?