2024-03-23 02:22:52 +00:00
|
|
|
#![cfg_attr(docsrs, feature(doc_auto_cfg))]
|
2024-03-25 18:52:50 +00:00
|
|
|
#![doc(
|
|
|
|
html_logo_url = "https://bevyengine.org/assets/icon.png",
|
|
|
|
html_favicon_url = "https://bevyengine.org/assets/icon.png"
|
|
|
|
)]
|
2024-03-23 02:22:52 +00:00
|
|
|
|
2023-09-27 07:08:09 +00:00
|
|
|
//! `bevy_window` provides a platform-agnostic interface for windowing in Bevy.
|
|
|
|
//!
|
|
|
|
//! This crate contains types for window management and events,
|
|
|
|
//! used by windowing implementors such as `bevy_winit`.
|
|
|
|
//! The [`WindowPlugin`] sets up some global window-related parameters and
|
|
|
|
//! is part of the [`DefaultPlugins`](https://docs.rs/bevy/latest/bevy/struct.DefaultPlugins.html).
|
Suppress the `clippy::type_complexity` lint (#8313)
# Objective
The clippy lint `type_complexity` is known not to play well with bevy.
It frequently triggers when writing complex queries, and taking the
lint's advice of using a type alias almost always just obfuscates the
code with no benefit. Because of this, this lint is currently ignored in
CI, but unfortunately it still shows up when viewing bevy code in an
IDE.
As someone who's made a fair amount of pull requests to this repo, I
will say that this issue has been a consistent thorn in my side. Since
bevy code is filled with spurious, ignorable warnings, it can be very
difficult to spot the *real* warnings that must be fixed -- most of the
time I just ignore all warnings, only to later find out that one of them
was real after I'm done when CI runs.
## Solution
Suppress this lint in all bevy crates. This was previously attempted in
#7050, but the review process ended up making it more complicated than
it needs to be and landed on a subpar solution.
The discussion in https://github.com/rust-lang/rust-clippy/pull/10571
explores some better long-term solutions to this problem. Since there is
no timeline on when these solutions may land, we should resolve this
issue in the meantime by locally suppressing these lints.
### Unresolved issues
Currently, these lints are not suppressed in our examples, since that
would require suppressing the lint in every single source file. They are
still ignored in CI.
2023-04-06 21:27:36 +00:00
|
|
|
|
2023-10-02 21:22:52 +00:00
|
|
|
use bevy_a11y::Focus;
|
|
|
|
|
2021-12-20 22:04:45 +00:00
|
|
|
mod cursor;
|
2020-04-19 19:13:04 +00:00
|
|
|
mod event;
|
Update `wgpu` to 0.14.0, `naga` to `0.10.0`, `winit` to 0.27.4, `raw-window-handle` to 0.5.0, `ndk` to 0.7 (#6218)
# Objective
- Update `wgpu` to 0.14.0, `naga` to `0.10.0`, `winit` to 0.27.4, `raw-window-handle` to 0.5.0, `ndk` to 0.7.
## Solution
---
## Changelog
### Changed
- Changed `RawWindowHandleWrapper` to `RawHandleWrapper` which wraps both `RawWindowHandle` and `RawDisplayHandle`, which satisfies the `impl HasRawWindowHandle and HasRawDisplayHandle` that `wgpu` 0.14.0 requires.
- Changed `bevy_window::WindowDescriptor`'s `cursor_locked` to `cursor_grab_mode`, change its type from `bool` to `bevy_window::CursorGrabMode`.
## Migration Guide
- Adjust usage of `bevy_window::WindowDescriptor`'s `cursor_locked` to `cursor_grab_mode`, and adjust its type from `bool` to `bevy_window::CursorGrabMode`.
2022-10-19 17:40:23 +00:00
|
|
|
mod raw_handle;
|
2020-04-19 19:13:04 +00:00
|
|
|
mod system;
|
2020-04-05 21:12:14 +00:00
|
|
|
mod window;
|
2020-03-30 21:53:32 +00:00
|
|
|
|
Update `wgpu` to 0.14.0, `naga` to `0.10.0`, `winit` to 0.27.4, `raw-window-handle` to 0.5.0, `ndk` to 0.7 (#6218)
# Objective
- Update `wgpu` to 0.14.0, `naga` to `0.10.0`, `winit` to 0.27.4, `raw-window-handle` to 0.5.0, `ndk` to 0.7.
## Solution
---
## Changelog
### Changed
- Changed `RawWindowHandleWrapper` to `RawHandleWrapper` which wraps both `RawWindowHandle` and `RawDisplayHandle`, which satisfies the `impl HasRawWindowHandle and HasRawDisplayHandle` that `wgpu` 0.14.0 requires.
- Changed `bevy_window::WindowDescriptor`'s `cursor_locked` to `cursor_grab_mode`, change its type from `bool` to `bevy_window::CursorGrabMode`.
## Migration Guide
- Adjust usage of `bevy_window::WindowDescriptor`'s `cursor_locked` to `cursor_grab_mode`, and adjust its type from `bool` to `bevy_window::CursorGrabMode`.
2022-10-19 17:40:23 +00:00
|
|
|
pub use crate::raw_handle::*;
|
2023-01-19 00:38:28 +00:00
|
|
|
|
2021-12-20 22:04:45 +00:00
|
|
|
pub use cursor::*;
|
2020-04-19 19:13:04 +00:00
|
|
|
pub use event::*;
|
|
|
|
pub use system::*;
|
2020-04-05 21:12:14 +00:00
|
|
|
pub use window::*;
|
2020-03-28 00:43:03 +00:00
|
|
|
|
2023-09-27 07:08:09 +00:00
|
|
|
#[allow(missing_docs)]
|
2020-07-20 09:05:56 +00:00
|
|
|
pub mod prelude {
|
2022-11-02 20:40:45 +00:00
|
|
|
#[doc(hidden)]
|
2020-12-03 19:30:27 +00:00
|
|
|
pub use crate::{
|
2023-01-29 20:27:29 +00:00
|
|
|
CursorEntered, CursorIcon, CursorLeft, CursorMoved, FileDragAndDrop, Ime, MonitorSelection,
|
2023-01-19 00:38:28 +00:00
|
|
|
ReceivedCharacter, Window, WindowMoved, WindowPlugin, WindowPosition,
|
|
|
|
WindowResizeConstraints,
|
2020-12-03 19:30:27 +00:00
|
|
|
};
|
2020-07-20 09:05:56 +00:00
|
|
|
}
|
|
|
|
|
2023-01-19 00:38:28 +00:00
|
|
|
use bevy_app::prelude::*;
|
|
|
|
|
Plugins own their settings. Rework PluginGroup trait. (#6336)
# Objective
Fixes #5884 #2879
Alternative to #2988 #5885 #2886
"Immutable" Plugin settings are currently represented as normal ECS resources, which are read as part of plugin init. This presents a number of problems:
1. If a user inserts the plugin settings resource after the plugin is initialized, it will be silently ignored (and use the defaults instead)
2. Users can modify the plugin settings resource after the plugin has been initialized. This creates a false sense of control over settings that can no longer be changed.
(1) and (2) are especially problematic and confusing for the `WindowDescriptor` resource, but this is a general problem.
## Solution
Immutable Plugin settings now live on each Plugin struct (ex: `WindowPlugin`). PluginGroups have been reworked to support overriding plugin values. This also removes the need for the `add_plugins_with` api, as the `add_plugins` api can use the builder pattern directly. Settings that can be used at runtime continue to be represented as ECS resources.
Plugins are now configured like this:
```rust
app.add_plugin(AssetPlugin {
watch_for_changes: true,
..default()
})
```
PluginGroups are now configured like this:
```rust
app.add_plugins(DefaultPlugins
.set(AssetPlugin {
watch_for_changes: true,
..default()
})
)
```
This is an alternative to #2988, which is similar. But I personally prefer this solution for a couple of reasons:
* ~~#2988 doesn't solve (1)~~ #2988 does solve (1) and will panic in that case. I was wrong!
* This PR directly ties plugin settings to Plugin types in a 1:1 relationship, rather than a loose "setup resource" <-> plugin coupling (where the setup resource is consumed by the first plugin that uses it).
* I'm not a huge fan of overloading the ECS resource concept and implementation for something that has very different use cases and constraints.
## Changelog
- PluginGroups can now be configured directly using the builder pattern. Individual plugin values can be overridden by using `plugin_group.set(SomePlugin {})`, which enables overriding default plugin values.
- `WindowDescriptor` plugin settings have been moved to `WindowPlugin` and `AssetServerSettings` have been moved to `AssetPlugin`
- `app.add_plugins_with` has been replaced by using `add_plugins` with the builder pattern.
## Migration Guide
The `WindowDescriptor` settings have been moved from a resource to `WindowPlugin::window`:
```rust
// Old (Bevy 0.8)
app
.insert_resource(WindowDescriptor {
width: 400.0,
..default()
})
.add_plugins(DefaultPlugins)
// New (Bevy 0.9)
app.add_plugins(DefaultPlugins.set(WindowPlugin {
window: WindowDescriptor {
width: 400.0,
..default()
},
..default()
}))
```
The `AssetServerSettings` resource has been removed in favor of direct `AssetPlugin` configuration:
```rust
// Old (Bevy 0.8)
app
.insert_resource(AssetServerSettings {
watch_for_changes: true,
..default()
})
.add_plugins(DefaultPlugins)
// New (Bevy 0.9)
app.add_plugins(DefaultPlugins.set(AssetPlugin {
watch_for_changes: true,
..default()
}))
```
`add_plugins_with` has been replaced by `add_plugins` in combination with the builder pattern:
```rust
// Old (Bevy 0.8)
app.add_plugins_with(DefaultPlugins, |group| group.disable::<AssetPlugin>());
// New (Bevy 0.9)
app.add_plugins(DefaultPlugins.build().disable::<AssetPlugin>());
```
2022-10-24 21:20:33 +00:00
|
|
|
impl Default for WindowPlugin {
|
|
|
|
fn default() -> Self {
|
|
|
|
WindowPlugin {
|
2023-01-19 00:38:28 +00:00
|
|
|
primary_window: Some(Window::default()),
|
|
|
|
exit_condition: ExitCondition::OnAllClosed,
|
Plugins own their settings. Rework PluginGroup trait. (#6336)
# Objective
Fixes #5884 #2879
Alternative to #2988 #5885 #2886
"Immutable" Plugin settings are currently represented as normal ECS resources, which are read as part of plugin init. This presents a number of problems:
1. If a user inserts the plugin settings resource after the plugin is initialized, it will be silently ignored (and use the defaults instead)
2. Users can modify the plugin settings resource after the plugin has been initialized. This creates a false sense of control over settings that can no longer be changed.
(1) and (2) are especially problematic and confusing for the `WindowDescriptor` resource, but this is a general problem.
## Solution
Immutable Plugin settings now live on each Plugin struct (ex: `WindowPlugin`). PluginGroups have been reworked to support overriding plugin values. This also removes the need for the `add_plugins_with` api, as the `add_plugins` api can use the builder pattern directly. Settings that can be used at runtime continue to be represented as ECS resources.
Plugins are now configured like this:
```rust
app.add_plugin(AssetPlugin {
watch_for_changes: true,
..default()
})
```
PluginGroups are now configured like this:
```rust
app.add_plugins(DefaultPlugins
.set(AssetPlugin {
watch_for_changes: true,
..default()
})
)
```
This is an alternative to #2988, which is similar. But I personally prefer this solution for a couple of reasons:
* ~~#2988 doesn't solve (1)~~ #2988 does solve (1) and will panic in that case. I was wrong!
* This PR directly ties plugin settings to Plugin types in a 1:1 relationship, rather than a loose "setup resource" <-> plugin coupling (where the setup resource is consumed by the first plugin that uses it).
* I'm not a huge fan of overloading the ECS resource concept and implementation for something that has very different use cases and constraints.
## Changelog
- PluginGroups can now be configured directly using the builder pattern. Individual plugin values can be overridden by using `plugin_group.set(SomePlugin {})`, which enables overriding default plugin values.
- `WindowDescriptor` plugin settings have been moved to `WindowPlugin` and `AssetServerSettings` have been moved to `AssetPlugin`
- `app.add_plugins_with` has been replaced by using `add_plugins` with the builder pattern.
## Migration Guide
The `WindowDescriptor` settings have been moved from a resource to `WindowPlugin::window`:
```rust
// Old (Bevy 0.8)
app
.insert_resource(WindowDescriptor {
width: 400.0,
..default()
})
.add_plugins(DefaultPlugins)
// New (Bevy 0.9)
app.add_plugins(DefaultPlugins.set(WindowPlugin {
window: WindowDescriptor {
width: 400.0,
..default()
},
..default()
}))
```
The `AssetServerSettings` resource has been removed in favor of direct `AssetPlugin` configuration:
```rust
// Old (Bevy 0.8)
app
.insert_resource(AssetServerSettings {
watch_for_changes: true,
..default()
})
.add_plugins(DefaultPlugins)
// New (Bevy 0.9)
app.add_plugins(DefaultPlugins.set(AssetPlugin {
watch_for_changes: true,
..default()
}))
```
`add_plugins_with` has been replaced by `add_plugins` in combination with the builder pattern:
```rust
// Old (Bevy 0.8)
app.add_plugins_with(DefaultPlugins, |group| group.disable::<AssetPlugin>());
// New (Bevy 0.9)
app.add_plugins(DefaultPlugins.build().disable::<AssetPlugin>());
```
2022-10-24 21:20:33 +00:00
|
|
|
close_when_requested: true,
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/// A [`Plugin`] that defines an interface for windowing support in Bevy.
|
|
|
|
pub struct WindowPlugin {
|
2023-07-30 15:46:16 +00:00
|
|
|
/// Settings for the primary window.
|
2022-05-05 13:35:43 +00:00
|
|
|
///
|
2023-07-30 15:46:16 +00:00
|
|
|
/// `Some(custom_window)` will spawn an entity with `custom_window` and [`PrimaryWindow`] as components.
|
|
|
|
/// `None` will not spawn a primary window.
|
|
|
|
///
|
|
|
|
/// Defaults to `Some(Window::default())`.
|
|
|
|
///
|
|
|
|
/// Note that if there are no windows the App will exit (by default) due to
|
|
|
|
/// [`exit_on_all_closed`].
|
2023-01-19 00:38:28 +00:00
|
|
|
pub primary_window: Option<Window>,
|
|
|
|
|
2022-05-05 13:35:43 +00:00
|
|
|
/// Whether to exit the app when there are no open windows.
|
2022-06-16 13:20:37 +00:00
|
|
|
///
|
2022-05-05 13:35:43 +00:00
|
|
|
/// If disabling this, ensure that you send the [`bevy_app::AppExit`]
|
|
|
|
/// event when the app should exit. If this does not occur, you will
|
|
|
|
/// create 'headless' processes (processes without windows), which may
|
2023-01-19 00:38:28 +00:00
|
|
|
/// surprise your users. It is recommended to leave this setting to
|
|
|
|
/// either [`ExitCondition::OnAllClosed`] or [`ExitCondition::OnPrimaryClosed`].
|
2022-05-05 13:35:43 +00:00
|
|
|
///
|
2023-03-18 01:45:34 +00:00
|
|
|
/// [`ExitCondition::OnAllClosed`] will add [`exit_on_all_closed`] to [`Update`].
|
|
|
|
/// [`ExitCondition::OnPrimaryClosed`] will add [`exit_on_primary_closed`] to [`Update`].
|
2023-01-19 00:38:28 +00:00
|
|
|
pub exit_condition: ExitCondition,
|
|
|
|
|
2022-05-05 13:35:43 +00:00
|
|
|
/// Whether to close windows when they are requested to be closed (i.e.
|
2022-06-16 13:20:37 +00:00
|
|
|
/// when the close button is pressed).
|
2022-05-05 13:35:43 +00:00
|
|
|
///
|
2023-03-18 01:45:34 +00:00
|
|
|
/// If true, this plugin will add [`close_when_requested`] to [`Update`].
|
2022-05-05 13:35:43 +00:00
|
|
|
/// If this system (or a replacement) is not running, the close button will have no effect.
|
|
|
|
/// This may surprise your users. It is recommended to leave this setting as `true`.
|
|
|
|
pub close_when_requested: bool,
|
2020-03-31 05:23:48 +00:00
|
|
|
}
|
|
|
|
|
2020-08-08 03:22:17 +00:00
|
|
|
impl Plugin for WindowPlugin {
|
2021-07-27 20:21:06 +00:00
|
|
|
fn build(&self, app: &mut App) {
|
2023-01-19 00:38:28 +00:00
|
|
|
// User convenience events
|
2020-04-06 23:15:59 +00:00
|
|
|
app.add_event::<WindowResized>()
|
2020-04-05 21:12:14 +00:00
|
|
|
.add_event::<WindowCreated>()
|
2022-05-05 13:35:43 +00:00
|
|
|
.add_event::<WindowClosed>()
|
2020-04-19 19:13:04 +00:00
|
|
|
.add_event::<WindowCloseRequested>()
|
2023-07-04 21:50:53 +00:00
|
|
|
.add_event::<WindowDestroyed>()
|
Reduce power usage with configurable event loop (#3974)
# Objective
- Reduce power usage for games when not focused.
- Reduce power usage to ~0 when a desktop application is minimized (opt-in).
- Reduce power usage when focused, only updating on a `winit` event, or the user sends a redraw request. (opt-in)
https://user-images.githubusercontent.com/2632925/156904387-ec47d7de-7f06-4c6f-8aaf-1e952c1153a2.mp4
Note resource usage in the Task Manager in the above video.
## Solution
- Added a type `UpdateMode` that allows users to specify how the winit event loop is updated, without exposing winit types.
- Added two fields to `WinitConfig`, both with the `UpdateMode` type. One configures how the application updates when focused, and the other configures how the application behaves when it is not focused. Users can modify this resource manually to set the type of event loop control flow they want.
- For convenience, two functions were added to `WinitConfig`, that provide reasonable presets: `game()` (default) and `desktop_app()`.
- The `game()` preset, which is used by default, is unchanged from current behavior with one exception: when the app is out of focus the app updates at a minimum of 10fps, or every time a winit event is received. This has a huge positive impact on power use and responsiveness on my machine, which will otherwise continue running the app at many hundreds of fps when out of focus or minimized.
- The `desktop_app()` preset is fully reactive, only updating when user input (winit event) is supplied or a `RedrawRequest` event is sent. When the app is out of focus, it only updates on `Window` events - i.e. any winit event that directly interacts with the window. What this means in practice is that the app uses *zero* resources when minimized or not interacted with, but still updates fluidly when the app is out of focus and the user mouses over the application.
- Added a `RedrawRequest` event so users can force an update even if there are no events. This is useful in an application when you want to, say, run an animation even when the user isn't providing input.
- Added an example `low_power` to demonstrate these changes
## Usage
Configuring the event loop:
```rs
use bevy::winit::{WinitConfig};
// ...
.insert_resource(WinitConfig::desktop_app()) // preset
// or
.insert_resource(WinitConfig::game()) // preset
// or
.insert_resource(WinitConfig{ .. }) // manual
```
Requesting a redraw:
```rs
use bevy::window::RequestRedraw;
// ...
fn request_redraw(mut event: EventWriter<RequestRedraw>) {
event.send(RequestRedraw);
}
```
## Other details
- Because we have a single event loop for multiple windows, every time I've mentioned "focused" above, I more precisely mean, "if at least one bevy window is focused".
- Due to a platform bug in winit (https://github.com/rust-windowing/winit/issues/1619), we can't simply use `Window::request_redraw()`. As a workaround, this PR will temporarily set the window mode to `Poll` when a redraw is requested. This is then reset to the user's `WinitConfig` setting on the next frame.
2022-03-07 23:32:05 +00:00
|
|
|
.add_event::<RequestRedraw>()
|
2020-06-04 06:22:32 +00:00
|
|
|
.add_event::<CursorMoved>()
|
2020-12-03 19:30:27 +00:00
|
|
|
.add_event::<CursorEntered>()
|
|
|
|
.add_event::<CursorLeft>()
|
2020-11-07 01:15:56 +00:00
|
|
|
.add_event::<ReceivedCharacter>()
|
2023-01-29 20:27:29 +00:00
|
|
|
.add_event::<Ime>()
|
2020-12-07 21:24:25 +00:00
|
|
|
.add_event::<WindowFocused>()
|
2023-11-26 21:58:54 +00:00
|
|
|
.add_event::<WindowOccluded>()
|
2020-12-28 20:26:50 +00:00
|
|
|
.add_event::<WindowScaleFactorChanged>()
|
|
|
|
.add_event::<WindowBackendScaleFactorChanged>()
|
2021-01-01 21:31:22 +00:00
|
|
|
.add_event::<FileDragAndDrop>()
|
2023-06-05 21:04:22 +00:00
|
|
|
.add_event::<WindowMoved>()
|
2023-10-23 20:47:55 +00:00
|
|
|
.add_event::<WindowThemeChanged>()
|
|
|
|
.add_event::<ApplicationLifetime>();
|
2023-01-19 00:38:28 +00:00
|
|
|
|
|
|
|
if let Some(primary_window) = &self.primary_window {
|
2023-10-02 21:22:52 +00:00
|
|
|
let initial_focus = app
|
2024-03-31 03:16:10 +00:00
|
|
|
.world_mut()
|
2023-01-19 00:38:28 +00:00
|
|
|
.spawn(primary_window.clone())
|
2023-10-02 21:22:52 +00:00
|
|
|
.insert(PrimaryWindow)
|
|
|
|
.id();
|
2024-03-31 03:16:10 +00:00
|
|
|
if let Some(mut focus) = app.world_mut().get_resource_mut::<Focus>() {
|
2023-10-02 21:22:52 +00:00
|
|
|
**focus = Some(initial_focus);
|
|
|
|
}
|
2020-03-28 00:43:03 +00:00
|
|
|
}
|
2020-04-19 19:13:04 +00:00
|
|
|
|
2023-01-19 00:38:28 +00:00
|
|
|
match self.exit_condition {
|
|
|
|
ExitCondition::OnPrimaryClosed => {
|
2023-03-18 01:45:34 +00:00
|
|
|
app.add_systems(PostUpdate, exit_on_primary_closed);
|
2023-01-19 00:38:28 +00:00
|
|
|
}
|
|
|
|
ExitCondition::OnAllClosed => {
|
2023-03-18 01:45:34 +00:00
|
|
|
app.add_systems(PostUpdate, exit_on_all_closed);
|
2023-01-19 00:38:28 +00:00
|
|
|
}
|
|
|
|
ExitCondition::DontExit => {}
|
2022-05-05 13:35:43 +00:00
|
|
|
}
|
2023-01-19 00:38:28 +00:00
|
|
|
|
Plugins own their settings. Rework PluginGroup trait. (#6336)
# Objective
Fixes #5884 #2879
Alternative to #2988 #5885 #2886
"Immutable" Plugin settings are currently represented as normal ECS resources, which are read as part of plugin init. This presents a number of problems:
1. If a user inserts the plugin settings resource after the plugin is initialized, it will be silently ignored (and use the defaults instead)
2. Users can modify the plugin settings resource after the plugin has been initialized. This creates a false sense of control over settings that can no longer be changed.
(1) and (2) are especially problematic and confusing for the `WindowDescriptor` resource, but this is a general problem.
## Solution
Immutable Plugin settings now live on each Plugin struct (ex: `WindowPlugin`). PluginGroups have been reworked to support overriding plugin values. This also removes the need for the `add_plugins_with` api, as the `add_plugins` api can use the builder pattern directly. Settings that can be used at runtime continue to be represented as ECS resources.
Plugins are now configured like this:
```rust
app.add_plugin(AssetPlugin {
watch_for_changes: true,
..default()
})
```
PluginGroups are now configured like this:
```rust
app.add_plugins(DefaultPlugins
.set(AssetPlugin {
watch_for_changes: true,
..default()
})
)
```
This is an alternative to #2988, which is similar. But I personally prefer this solution for a couple of reasons:
* ~~#2988 doesn't solve (1)~~ #2988 does solve (1) and will panic in that case. I was wrong!
* This PR directly ties plugin settings to Plugin types in a 1:1 relationship, rather than a loose "setup resource" <-> plugin coupling (where the setup resource is consumed by the first plugin that uses it).
* I'm not a huge fan of overloading the ECS resource concept and implementation for something that has very different use cases and constraints.
## Changelog
- PluginGroups can now be configured directly using the builder pattern. Individual plugin values can be overridden by using `plugin_group.set(SomePlugin {})`, which enables overriding default plugin values.
- `WindowDescriptor` plugin settings have been moved to `WindowPlugin` and `AssetServerSettings` have been moved to `AssetPlugin`
- `app.add_plugins_with` has been replaced by using `add_plugins` with the builder pattern.
## Migration Guide
The `WindowDescriptor` settings have been moved from a resource to `WindowPlugin::window`:
```rust
// Old (Bevy 0.8)
app
.insert_resource(WindowDescriptor {
width: 400.0,
..default()
})
.add_plugins(DefaultPlugins)
// New (Bevy 0.9)
app.add_plugins(DefaultPlugins.set(WindowPlugin {
window: WindowDescriptor {
width: 400.0,
..default()
},
..default()
}))
```
The `AssetServerSettings` resource has been removed in favor of direct `AssetPlugin` configuration:
```rust
// Old (Bevy 0.8)
app
.insert_resource(AssetServerSettings {
watch_for_changes: true,
..default()
})
.add_plugins(DefaultPlugins)
// New (Bevy 0.9)
app.add_plugins(DefaultPlugins.set(AssetPlugin {
watch_for_changes: true,
..default()
}))
```
`add_plugins_with` has been replaced by `add_plugins` in combination with the builder pattern:
```rust
// Old (Bevy 0.8)
app.add_plugins_with(DefaultPlugins, |group| group.disable::<AssetPlugin>());
// New (Bevy 0.9)
app.add_plugins(DefaultPlugins.build().disable::<AssetPlugin>());
```
2022-10-24 21:20:33 +00:00
|
|
|
if self.close_when_requested {
|
2023-02-13 19:15:24 +00:00
|
|
|
// Need to run before `exit_on_*` systems
|
2023-03-18 01:45:34 +00:00
|
|
|
app.add_systems(Update, close_when_requested);
|
2020-04-19 19:13:04 +00:00
|
|
|
}
|
2022-12-09 01:20:44 +00:00
|
|
|
|
|
|
|
// Register event types
|
|
|
|
app.register_type::<WindowResized>()
|
|
|
|
.register_type::<RequestRedraw>()
|
|
|
|
.register_type::<WindowCreated>()
|
|
|
|
.register_type::<WindowCloseRequested>()
|
|
|
|
.register_type::<WindowClosed>()
|
|
|
|
.register_type::<CursorMoved>()
|
|
|
|
.register_type::<CursorEntered>()
|
|
|
|
.register_type::<CursorLeft>()
|
|
|
|
.register_type::<ReceivedCharacter>()
|
|
|
|
.register_type::<WindowFocused>()
|
2023-11-26 21:58:54 +00:00
|
|
|
.register_type::<WindowOccluded>()
|
2022-12-09 01:20:44 +00:00
|
|
|
.register_type::<WindowScaleFactorChanged>()
|
|
|
|
.register_type::<WindowBackendScaleFactorChanged>()
|
|
|
|
.register_type::<FileDragAndDrop>()
|
2023-06-05 21:04:22 +00:00
|
|
|
.register_type::<WindowMoved>()
|
2023-10-23 20:47:55 +00:00
|
|
|
.register_type::<WindowThemeChanged>()
|
|
|
|
.register_type::<ApplicationLifetime>();
|
2022-12-09 01:20:44 +00:00
|
|
|
|
|
|
|
// Register window descriptor and related types
|
2023-01-19 00:38:28 +00:00
|
|
|
app.register_type::<Window>()
|
2024-03-06 16:05:53 +00:00
|
|
|
.register_type::<PrimaryWindow>();
|
2020-03-28 00:43:03 +00:00
|
|
|
}
|
2020-04-06 23:15:59 +00:00
|
|
|
}
|
2022-04-25 14:32:56 +00:00
|
|
|
|
2023-01-19 00:38:28 +00:00
|
|
|
/// Defines the specific conditions the application should exit on
|
|
|
|
#[derive(Clone)]
|
|
|
|
pub enum ExitCondition {
|
|
|
|
/// Close application when the primary window is closed
|
|
|
|
///
|
2023-03-18 01:45:34 +00:00
|
|
|
/// The plugin will add [`exit_on_primary_closed`] to [`Update`].
|
2023-01-19 00:38:28 +00:00
|
|
|
OnPrimaryClosed,
|
|
|
|
/// Close application when all windows are closed
|
|
|
|
///
|
2023-03-18 01:45:34 +00:00
|
|
|
/// The plugin will add [`exit_on_all_closed`] to [`Update`].
|
2023-01-19 00:38:28 +00:00
|
|
|
OnAllClosed,
|
|
|
|
/// Keep application running headless even after closing all windows
|
|
|
|
///
|
|
|
|
/// If selecting this, ensure that you send the [`bevy_app::AppExit`]
|
|
|
|
/// event when the app should exit. If this does not occur, you will
|
|
|
|
/// create 'headless' processes (processes without windows), which may
|
|
|
|
/// surprise your users.
|
|
|
|
DontExit,
|
|
|
|
}
|