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.

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

Programmatically exit an Application with ExitEvent triggered #548

Open
4 tasks
mosra opened this issue Jan 18, 2022 · 0 comments
Open
4 tasks

Programmatically exit an Application with ExitEvent triggered #548

mosra opened this issue Jan 18, 2022 · 0 comments
Projects

Comments

@mosra
Copy link
Owner

mosra commented Jan 18, 2022

Simple request with a nontrivial solution, as usual. Right now, calling exit() on GLFW/SDL2 application just stops executing the main loop, which unconditionally leads to resource cleanup and exiting the program. In particular, the ExitEvent, allowing the exit to be aborted, is not fired here. That means there's no builtin way to request application exit via, say, a button in the application UI and have it behave the same way as if the window close button was clicked.

In case of SDL2, this behavior can be implemented by manually pushing an exit event instead of calling exit(), however that doesn't allow the user to specify the exit code:

SDL_Event quit{};
quit.type = SDL_QUIT;
SDL_PushEvent(&quit);

In case of GLFW, there unfortunately doesn't seem to be a builtin way, glfwSetWindowShouldClose(window(), true) leads to an unconditional stop of the event loop, with the callback from glfwSetWindowCloseCallback() never entered. Possibly related issue that could allow posting "fake" events to implement this: glfw/glfw#688

Alternatively, this could be implemented outside of SDL/GLFW, simply by firing the ExitEvent if an exit is requested, and then possibly cancelling the exit.

Things to do:

  • Document the current behavior, so it's clear exit() sidesteps the ExitEvent
  • Implement this for SDL and GLFW, outside of their event loop to have common handling for both
    • Having ExitEvent fired from exit() might not make sense in all cases, especially when the app wants to unconditionally exit due to some unrecovarable failure, or from a constructor (or maybe from the constructor it wouldn't trigger the event?), so maybe a new requestExit() API with this behavior might make sense instead?
  • Possibly related: on iOS OTOH, the exit() doesn't seem to do an actual quit, just stops event processing: https://gitter.im/mosra/magnum/archives/2022/01/11?at=61dcc94b9b470f38975db494

Cc: @jvannugteren @hsdk123

@mosra mosra added this to TODO in Platforms via automation Jan 18, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Platforms
  
TODO
Development

No branches or pull requests

1 participant