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

how to handle PrimaryWindow despawning #13698

Open
mockersf opened this issue Jun 5, 2024 · 3 comments
Open

how to handle PrimaryWindow despawning #13698

mockersf opened this issue Jun 5, 2024 · 3 comments
Labels
A-Rendering Drawing game state to the screen A-Windowing Platform-agnostic interface layer to run your app in C-Docs An addition or correction to our documentation S-Needs-Design This issue requires design work to think about how it would best be accomplished

Comments

@mockersf
Copy link
Member

mockersf commented Jun 5, 2024

When despawning the PrimaryWindow, what should happen?

  • Should it be forbidden?
  • Should a new window be promoted as the new PrimaryWindow?
  • Should we continue without a PrimaryWindow?
  • (also true for other windows) Should cameras targeting the PrimaryWindow be despawned?
@mockersf mockersf added C-Docs An addition or correction to our documentation A-Rendering Drawing game state to the screen A-Windowing Platform-agnostic interface layer to run your app in S-Needs-Design This issue requires design work to think about how it would best be accomplished labels Jun 5, 2024
@mockersf mockersf changed the title how to handle PrimaryWIndow despawning how to handle PrimaryWindow despawning Jun 5, 2024
@alice-i-cecile
Copy link
Member

IMO, we should handle this as gracefully as possible, as long as we expose an on-by-default way to prevent the primary window from being closed without killing the app. That means promoting another window to take its place.

When windows are despawned, we should despawn any cameras targeting them. Down the line, this should be enforced through the use of relations with the "despawn when the paired entity is missing" behavior.

@tychedelia
Copy link
Contributor

It would be pretty counter intuitive to me that a secondary window would be "promoted" the primary window when the first closes. We also already allow the user to configure the exit condition. Maybe I'm missing some context, but this doesn't seem like the kind of thing there is a sensible default for in multi-window scenarios. I think I am probably working with multi-window apps more than the average user, and personally I always disable primary window function on the default plugin.

@bushrat011899
Copy link
Contributor

I agree that promoting an arbitrary window to become the PrimaryWindow doesn't seem like the right response here. In some apps it makes sense (e.g., a web browser where other windows are basically just the primary window again) but in others I could see it being very confusing (e.g., the CAD application I use spawns a second window just for a couple of tools, promoting that to the primary window seems odd).

Perhaps a window could be annotated with a SecondaryWindow component indicating that it is appropriate to promote that window into a PrimaryWindow when the primary is destroyed? If no secondary windows are available to promote, then I would expect the application to gracefully quit by default. However, that last step should be configurable for more niche use cases.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Rendering Drawing game state to the screen A-Windowing Platform-agnostic interface layer to run your app in C-Docs An addition or correction to our documentation S-Needs-Design This issue requires design work to think about how it would best be accomplished
Projects
None yet
Development

No branches or pull requests

4 participants