Windows as Entities

[Weibye]

Objective

Windows as Entities

Solution

What solution would you like?

• WindowId is now Entity
• Extend Commands with a window method returns WindowCommands similar to how the entity method returns EntityCommands,
• WindowCommandQueued will implement Command and on write send itself as an event that window backends like bevy_winit will process.
• Window should be separated into different components:
  • WindowCursor
  • WindowCursorPosition
  • WindowHandle
  • WindowPosition
  • WindowResizeConstraints
  • WindowResolution
  • WindowTitle
  • WindowPresentation
  • WindowModeComponent
  • WindowCurrentlyFocused (marker) (WindowFocused is taken by a window event)
  • WindowDecorated (marker)
  • WindowResizable (marker)
  • A world query struct containing all these components and markers should be publicly exposed
• Windows should be spawned like an entity in Commands with a WindowDescriptor component
• Window backends should query Added and create the windows for them
• while also applying a Window marker confirming they have been created, query Added or use a WindowCreated event to get newly created windows.
• Despawning windows should be done just as entities (as they are now entities), window backends should close/destroy windows their internal component has been dropped, e.g. WinitWindow (wrapper around winit's Window that destroys itself on drop)
• A resource called PrimaryWindow contains the entity id of initial window created by WindowPlugin, this replaces Windows::primary
• Insert PrimaryWindow resource when primary window has been created
• PrimaryWindow when add_primary_window is false?
• WindowPlugin should change exit_on_close into a enum called ExitCondition with the values OnPrimaryClosed (when primary window is closed), OnAllClosed (when all windows are closed), DontExit (keep app headless)

---

Changelog

This section is optional. If this was a trivial fix, or has no externally-visible impact, you can delete this section.

• What changed as a result of this PR?
• If applicable, organize changes under "Added", "Changed", or "Fixed" sub-headings
• Stick to one or two sentences. If more detail is needed for a particular change, consider adding it to the "Solution" section
  • If you can't summarize the work, your change may be unreasonably large / unrelated. Consider splitting your PR to make it easier to review and merge!

Migration Guide

This section is optional. If there are no breaking changes, you can delete this section.

• If this PR is a breaking change (relative to the last release of Bevy), describe how a user might need to migrate their code to support these changes
• Simply adding new functionality is not a breaking change.
• Fixing behavior that was definitely a bug, rather than a questionable design choice is not a breaking change.

[alice-i-cecile]

Can you set the PR title to Windows as Entities? And clean up the PR description of course once you're ready.

[Weibye]

Ah, I was planning to set up this as a pr to my own fork for initial work and prototyping, but I seem to have targeted the wrong repo. (Which is why the PR is so messy atm)

I'm going to close this one out, but going to keep working here if you'd like to check on the work every now and again: Weibye#1