2022-05-16 13:53:20 +00:00
|
|
|
//! Illustrates how to change window settings and shows how to affect
|
|
|
|
//! the mouse pointer in various ways.
|
|
|
|
|
2022-09-30 13:25:27 +00:00
|
|
|
use bevy::{
|
|
|
|
diagnostic::{FrameTimeDiagnosticsPlugin, LogDiagnosticsPlugin},
|
|
|
|
prelude::*,
|
2023-06-05 21:04:22 +00:00
|
|
|
window::{CursorGrabMode, PresentMode, WindowLevel, WindowTheme},
|
2022-09-30 13:25:27 +00:00
|
|
|
};
|
2020-07-20 09:05:56 +00:00
|
|
|
|
|
|
|
fn main() {
|
2021-07-27 20:21:06 +00:00
|
|
|
App::new()
|
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
|
|
|
.add_plugins(DefaultPlugins.set(WindowPlugin {
|
2023-01-19 00:38:28 +00:00
|
|
|
primary_window: Some(Window {
|
|
|
|
title: "I am a window!".into(),
|
|
|
|
resolution: (500., 300.).into(),
|
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
|
|
|
present_mode: PresentMode::AutoVsync,
|
2023-01-19 00:38:28 +00:00
|
|
|
// Tells wasm to resize the window according to the available canvas
|
|
|
|
fit_canvas_to_parent: true,
|
Allow not preventing default event behaviors on wasm (#7304)
# Objective
On wasm, bevy applications currently prevent any of the normal browser hotkeys from working normally (Ctrl+R, F12, F5, Ctrl+F5, tab, etc.).
Some of those events you may want to override, perhaps you can hold the tab key for showing in-game stats?
However, if you want to make a well-behaved game, you probably don't want to needlessly prevent that behavior unless you have a good reason.
Secondary motivation: Also, consider the workaround presented here to get audio working: https://developer.chrome.com/blog/web-audio-autoplay/#moving-forward ; It won't work (for keydown events) if we stop event propagation.
## Solution
- Winit has a field that allows it to not stop event propagation, expose it on the window settings to allow the user to choose the desired behavior. Default to `true` for backwards compatibility.
---
## Changelog
- Added `Window::prevent_default_event_handling` . This allows bevy apps to not override default browser behavior on hotkeys like F5, F12, Ctrl+R etc.
2023-01-22 23:35:32 +00:00
|
|
|
// Tells wasm not to override default event handling, like F5, Ctrl+R etc.
|
|
|
|
prevent_default_event_handling: false,
|
2023-06-05 21:04:22 +00:00
|
|
|
window_theme: Some(WindowTheme::Dark),
|
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
|
|
|
..default()
|
2023-01-19 00:38:28 +00:00
|
|
|
}),
|
2022-03-01 20:52:09 +00:00
|
|
|
..default()
|
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
|
|
|
}))
|
2022-09-21 22:35:15 +00:00
|
|
|
.add_plugin(LogDiagnosticsPlugin::default())
|
|
|
|
.add_plugin(FrameTimeDiagnosticsPlugin)
|
2023-03-18 01:45:34 +00:00
|
|
|
.add_systems(
|
|
|
|
Update,
|
|
|
|
(
|
|
|
|
change_title,
|
2023-06-05 21:04:22 +00:00
|
|
|
toggle_theme,
|
2023-03-18 01:45:34 +00:00
|
|
|
toggle_cursor,
|
|
|
|
toggle_vsync,
|
|
|
|
cycle_cursor_icon,
|
|
|
|
switch_level,
|
|
|
|
),
|
|
|
|
)
|
2020-07-20 09:05:56 +00:00
|
|
|
.run();
|
|
|
|
}
|
2020-10-15 18:42:19 +00:00
|
|
|
|
2022-09-21 22:35:15 +00:00
|
|
|
/// This system toggles the vsync mode when pressing the button V.
|
|
|
|
/// You'll see fps increase displayed in the console.
|
2023-01-19 00:38:28 +00:00
|
|
|
fn toggle_vsync(input: Res<Input<KeyCode>>, mut windows: Query<&mut Window>) {
|
2022-09-21 22:35:15 +00:00
|
|
|
if input.just_pressed(KeyCode::V) {
|
2023-01-19 00:38:28 +00:00
|
|
|
let mut window = windows.single_mut();
|
2022-09-21 22:35:15 +00:00
|
|
|
|
2023-01-19 00:38:28 +00:00
|
|
|
window.present_mode = if matches!(window.present_mode, PresentMode::AutoVsync) {
|
2022-09-21 22:35:15 +00:00
|
|
|
PresentMode::AutoNoVsync
|
|
|
|
} else {
|
|
|
|
PresentMode::AutoVsync
|
2023-01-19 00:38:28 +00:00
|
|
|
};
|
|
|
|
info!("PRESENT_MODE: {:?}", window.present_mode);
|
2022-09-21 22:35:15 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2023-02-03 16:41:39 +00:00
|
|
|
/// This system switches the window level when pressing the T button
|
|
|
|
/// You'll notice it won't be covered by other windows, or will be covered by all the other
|
|
|
|
/// windows depending on the level.
|
2022-11-14 22:34:29 +00:00
|
|
|
///
|
|
|
|
/// This feature only works on some platforms. Please check the
|
2023-02-03 16:41:39 +00:00
|
|
|
/// [documentation](https://docs.rs/bevy/latest/bevy/prelude/struct.Window.html#structfield.window_level)
|
2022-11-14 22:34:29 +00:00
|
|
|
/// for more details.
|
2023-02-03 16:41:39 +00:00
|
|
|
fn switch_level(input: Res<Input<KeyCode>>, mut windows: Query<&mut Window>) {
|
2022-11-14 22:34:29 +00:00
|
|
|
if input.just_pressed(KeyCode::T) {
|
2023-01-19 00:38:28 +00:00
|
|
|
let mut window = windows.single_mut();
|
2022-11-14 22:34:29 +00:00
|
|
|
|
2023-02-03 16:41:39 +00:00
|
|
|
window.window_level = match window.window_level {
|
|
|
|
WindowLevel::AlwaysOnBottom => WindowLevel::Normal,
|
|
|
|
WindowLevel::Normal => WindowLevel::AlwaysOnTop,
|
|
|
|
WindowLevel::AlwaysOnTop => WindowLevel::AlwaysOnBottom,
|
|
|
|
};
|
|
|
|
info!("WINDOW_LEVEL: {:?}", window.window_level);
|
2022-11-14 22:34:29 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-10-15 18:42:19 +00:00
|
|
|
/// This system will then change the title during execution
|
2023-01-19 00:38:28 +00:00
|
|
|
fn change_title(mut windows: Query<&mut Window>, time: Res<Time>) {
|
|
|
|
let mut window = windows.single_mut();
|
|
|
|
window.title = format!(
|
2020-10-15 18:42:19 +00:00
|
|
|
"Seconds since startup: {}",
|
2023-01-19 00:38:28 +00:00
|
|
|
time.elapsed().as_secs_f32().round()
|
|
|
|
);
|
2020-10-15 18:42:19 +00:00
|
|
|
}
|
2020-10-16 21:07:01 +00:00
|
|
|
|
2023-01-19 00:38:28 +00:00
|
|
|
fn toggle_cursor(mut windows: Query<&mut Window>, input: Res<Input<KeyCode>>) {
|
2020-10-16 21:07:01 +00:00
|
|
|
if input.just_pressed(KeyCode::Space) {
|
2023-01-19 00:38:28 +00:00
|
|
|
let mut window = windows.single_mut();
|
|
|
|
|
|
|
|
window.cursor.visible = !window.cursor.visible;
|
|
|
|
window.cursor.grab_mode = match window.cursor.grab_mode {
|
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
|
|
|
CursorGrabMode::None => CursorGrabMode::Locked,
|
|
|
|
CursorGrabMode::Locked | CursorGrabMode::Confined => CursorGrabMode::None,
|
2023-01-19 00:38:28 +00:00
|
|
|
};
|
2020-10-16 21:07:01 +00:00
|
|
|
}
|
|
|
|
}
|
2021-12-20 22:04:45 +00:00
|
|
|
|
2023-06-05 21:04:22 +00:00
|
|
|
// This system will toggle the color theme used by the window
|
|
|
|
fn toggle_theme(mut windows: Query<&mut Window>, input: Res<Input<KeyCode>>) {
|
|
|
|
if input.just_pressed(KeyCode::F) {
|
|
|
|
let mut window = windows.single_mut();
|
|
|
|
|
|
|
|
if let Some(current_theme) = window.window_theme {
|
|
|
|
window.window_theme = match current_theme {
|
|
|
|
WindowTheme::Light => Some(WindowTheme::Dark),
|
|
|
|
WindowTheme::Dark => Some(WindowTheme::Light),
|
|
|
|
};
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-12-20 22:04:45 +00:00
|
|
|
/// This system cycles the cursor's icon through a small set of icons when clicking
|
|
|
|
fn cycle_cursor_icon(
|
2023-01-19 00:38:28 +00:00
|
|
|
mut windows: Query<&mut Window>,
|
2021-12-20 22:04:45 +00:00
|
|
|
input: Res<Input<MouseButton>>,
|
|
|
|
mut index: Local<usize>,
|
|
|
|
) {
|
2023-01-19 00:38:28 +00:00
|
|
|
let mut window = windows.single_mut();
|
|
|
|
|
2021-12-20 22:04:45 +00:00
|
|
|
const ICONS: &[CursorIcon] = &[
|
|
|
|
CursorIcon::Default,
|
|
|
|
CursorIcon::Hand,
|
|
|
|
CursorIcon::Wait,
|
|
|
|
CursorIcon::Text,
|
|
|
|
CursorIcon::Copy,
|
|
|
|
];
|
2023-01-19 00:38:28 +00:00
|
|
|
|
2021-12-20 22:04:45 +00:00
|
|
|
if input.just_pressed(MouseButton::Left) {
|
|
|
|
*index = (*index + 1) % ICONS.len();
|
|
|
|
} else if input.just_pressed(MouseButton::Right) {
|
|
|
|
*index = if *index == 0 {
|
|
|
|
ICONS.len() - 1
|
|
|
|
} else {
|
|
|
|
*index - 1
|
|
|
|
};
|
|
|
|
}
|
2023-01-19 00:38:28 +00:00
|
|
|
|
|
|
|
window.cursor.icon = ICONS[*index];
|
2021-12-20 22:04:45 +00:00
|
|
|
}
|