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:
  • WindowsCommandQueue
  • 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<Window> 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

• WindowId has been replaced by Entity
• Window has been split into multiple components:
  • Window (marker)
  • WindowCursor
  • WindowCursorPosition
  • WindowHandle
  • WindowPresentation
  • WindowModeComponent
  • WindowPosition
  • WindowResolution
  • WindowTitle
  • WindowCanvas
  • WindowDecoraded (marker)
  • WindowCurrentlyFocused (marker)
  • WindowResizable (marker)
  • WindowTransparent (marker)
  • WindowMinimized (marker)
  • WindowMaximized (marker)
• Created WindowCommandsExtensions so that we can commands.window(entity) to get WindowCommands
  • Similar to how ÈntityCommands work
• Split enum WindowCommand into separate structs that all impl Command
• Most methods previously existing on Window is now ei
• Removed Windows as this should now be accomplished by querying for entities with the Window marker component: Query<Entity, With<Window>>

Migration Guide

• bevy_render
• bevy_window
• bevy_text
• bevy_ui
• bevy_winit
• examples

[Weibye]

Process flow:

1. WindowPlugin sends window_event(CreateWindow { windowDescriptor })
2. WinitPlugin creates the runner and runs
3. handle_create_window_events()

[Weibye]

2. Should all WindowComponents be read-only?
3. User request changes happening through WindowCommands
4. Window backend consumes the command queue and updates the components accordingly

• Updates the WinitWindow
• Updates the corresponding Component

6. The changed components can now be queried by the user

Or

1. User changes the WindowComponent
2. Window backend listens for Changed events, when updates the WinitWindow accordinly?

[Weibye]

Current way the user interacts with windows:

1. User uses WindowCommands to queue operations to be performed on the window
2. Backend resolves the commands and updates the corresponding window-components
3. The user can look at the window-components in a read-only fashion

[Weibye]

Type inconsitencies:

Cursor position

• WindowCursorPosition.position: Option<DVec2>
• SetCursorPositionCommand.position: Vec2
• Winit has PhysicalPosition<i32> and LogicalPosition<f64>
• CursorPosition now uses DVec2 all the way though