Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Event::LoopDestroyed not always emmited #1998

Closed
emilk opened this issue Aug 15, 2021 · 3 comments · Fixed by #2073
Closed

Event::LoopDestroyed not always emmited #1998

emilk opened this issue Aug 15, 2021 · 3 comments · Fixed by #2073
Labels
B - bug Dang, that shouldn't have happened C - waiting on author Waiting for a response or another PR DS - macos
Milestone
Version 0.27

Comments

@emilk
Copy link
Contributor

emilk commented Aug 15, 2021

On Mac, when I press Cmd+Q the window closes, but there is no Event::LoopDestroyed emitted, so I cannot save my program state.

winit version: 0.25.0, used via glium/glutin.
@emilk emilk mentioned this issue Aug 15, 2021
Closed
@maroider maroider added DS - macos C - needs investigation Issue must be confirmed and researched B - bug Dang, that shouldn't have happened labels Aug 15, 2021
emilk added a commit to emilk/egui that referenced this issue Nov 6, 2021
@emilk
winit: don't explicitly handle Cmd-Q and Alt-F4
5b33c48 
Closes #877

Still a problem: rust-windowing/winit#1998
@emilk emilk mentioned this issue Nov 6, 2021
Merged
emilk added a commit to emilk/egui that referenced this issue Nov 6, 2021
@emilk
winit: don't explicitly handle Cmd-Q and Alt-F4
d885fac 
Closes #877

Still a problem: rust-windowing/winit#1998
emilk added a commit to emilk/egui that referenced this issue Nov 7, 2021
@emilk
winit: don't explicitly handle Cmd-Q and Alt-F4 (#881)
ddd5f6f 
Closes #877

Still a problem: rust-windowing/winit#1998
@tinaun
Copy link
Contributor

tinaun commented Nov 25, 2021

I think this can be fixed by overriding applicationWillTerminate: to send a LoopDestroyed event in winits appdelegate

@tinaun tinaun mentioned this issue Nov 25, 2021
Merged
8 tasks
@madsmtm
Copy link
Member

madsmtm commented Nov 26, 2021

Huh, this changed in #1583 when a default macOS menu was added, because as it registers the Quit {process_name}, it also registers the key combination for it. It was even pointed out here: #1583 (comment), sorry it slipped past the changelog!

@madsmtm
Copy link
Member

madsmtm commented Nov 26, 2021 •
edited
Loading

An alternative to the proposed PR would be to use the stop: selector in menu.rs instead of terminate:; this would allow run_return to resume, if I'm not mistaken? And the teardown code after [app run] would be called properly.

Though I don't really have a preference

@madsmtm madsmtm added C - waiting on author Waiting for a response or another PR and removed C - needs investigation Issue must be confirmed and researched labels Jan 3, 2022
madsmtm added a commit to madsmtm/winit that referenced this issue Mar 21, 2022
@madsmtm
macOS: Fix emitting Event::LoopDestroyed on CMD+Q / Quit
208e433 
Fixes rust-windowing#1998

Alternative: rust-windowing#2073
@madsmtm madsmtm mentioned this issue Mar 21, 2022
Closed
5 tasks
@madsmtm madsmtm added this to the Version 0.27 milestone Jun 9, 2022
@fredizzimo fredizzimo mentioned this issue Sep 23, 2023
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
B - bug Dang, that shouldn't have happened C - waiting on author Waiting for a response or another PR DS - macos
Milestone
Version 0.27
4 participants
@emilk @tinaun @madsmtm @maroider