Rename LoopDestroyed to LoopExiting

Considering the possibility of re-running an event loop via run_ondemand
then it's more correct to say that the loop is about to exit without
assuming it's going to be destroyed.
This commit is contained in:
Robert Bragg
2023-07-28 17:19:53 +01:00
committed by Kirill Chibisov
parent 7de2bc7ae6
commit 3bf0fa9ec8
15 changed files with 28 additions and 30 deletions

View File

@@ -444,10 +444,7 @@ impl AppState {
fn terminated_transition(&mut self) -> Box<dyn EventHandler> {
match self.replace_state(AppStateImpl::Terminated) {
AppStateImpl::ProcessingEvents { event_handler, .. } => event_handler,
s => bug!(
"`LoopDestroyed` happened while not processing events {:?}",
s
),
s => bug!("`LoopExiting` happened while not processing events {:?}", s),
}
}
}
@@ -785,7 +782,7 @@ pub unsafe fn terminated() {
let mut control_flow = this.control_flow;
drop(this);
event_handler.handle_nonuser_event(Event::LoopDestroyed, &mut control_flow)
event_handler.handle_nonuser_event(Event::LoopExiting, &mut control_flow)
}
fn handle_event_proxy(

View File

@@ -48,12 +48,12 @@
//!
//! - applicationDidBecomeActive is Resumed
//! - applicationWillResignActive is Suspended
//! - applicationWillTerminate is LoopDestroyed
//! - applicationWillTerminate is LoopExiting
//!
//! Keep in mind that after LoopDestroyed event is received every attempt to draw with
//! Keep in mind that after LoopExiting event is received every attempt to draw with
//! opengl will result in segfault.
//!
//! Also note that app may not receive the LoopDestroyed event if suspended; it might be SIGKILL'ed.
//! Also note that app may not receive the LoopExiting event if suspended; it might be SIGKILL'ed.
#![cfg(ios_platform)]
#![allow(clippy::let_unit_value)]