
# Objective Fixes a part of #14274. Bevy has an incredibly inconsistent naming convention for its system sets, both internally and across the ecosystem. <img alt="System sets in Bevy" src="https://github.com/user-attachments/assets/d16e2027-793f-4ba4-9cc9-e780b14a5a1b" width="450" /> *Names of public system set types in Bevy* Most Bevy types use a naming of `FooSystem` or just `Foo`, but there are also a few `FooSystems` and `FooSet` types. In ecosystem crates on the other hand, `FooSet` is perhaps the most commonly used name in general. Conventions being so wildly inconsistent can make it harder for users to pick names for their own types, to search for system sets on docs.rs, or to even discern which types *are* system sets. To reign in the inconsistency a bit and help unify the ecosystem, it would be good to establish a common recommended naming convention for system sets in Bevy itself, similar to how plugins are commonly suffixed with `Plugin` (ex: `TimePlugin`). By adopting a consistent naming convention in first-party Bevy, we can softly nudge ecosystem crates to follow suit (for types where it makes sense to do so). Choosing a naming convention is also relevant now, as the [`bevy_cli` recently adopted lints](https://github.com/TheBevyFlock/bevy_cli/pull/345) to enforce naming for plugins and system sets, and the recommended naming used for system sets is still a bit open. ## Which Name To Use? Now the contentious part: what naming convention should we actually adopt? This was discussed on the Bevy Discord at the end of last year, starting [here](<https://discord.com/channels/691052431525675048/692572690833473578/1310659954683936789>). `FooSet` and `FooSystems` were the clear favorites, with `FooSet` very narrowly winning an unofficial poll. However, it seems to me like the consensus was broadly moving towards `FooSystems` at the end and after the poll, with Cart ([source](https://discord.com/channels/691052431525675048/692572690833473578/1311140204974706708)) and later Alice ([source](https://discord.com/channels/691052431525675048/692572690833473578/1311092530732859533)) and also me being in favor of it. Let's do a quick pros and cons list! Of course these are just what I thought of, so take it with a grain of salt. `FooSet`: - Pro: Nice and short! - Pro: Used by many ecosystem crates. - Pro: The `Set` suffix comes directly from the trait name `SystemSet`. - Pro: Pairs nicely with existing APIs like `in_set` and `configure_sets`. - Con: `Set` by itself doesn't actually indicate that it's related to systems *at all*, apart from the implemented trait. A set of what? - Con: Is `FooSet` a set of `Foo`s or a system set related to `Foo`? Ex: `ContactSet`, `MeshSet`, `EnemySet`... `FooSystems`: - Pro: Very clearly indicates that the type represents a collection of systems. The actual core concept, system(s), is in the name. - Pro: Parallels nicely with `FooPlugins` for plugin groups. - Pro: Low risk of conflicts with other names or misunderstandings about what the type is. - Pro: In most cases, reads *very* nicely and clearly. Ex: `PhysicsSystems` and `AnimationSystems` as opposed to `PhysicsSet` and `AnimationSet`. - Pro: Easy to search for on docs.rs. - Con: Usually results in longer names. - Con: Not yet as widely used. Really the big problem with `FooSet` is that it doesn't actually describe what it is. It describes what *kind of thing* it is (a set of something), but not *what it is a set of*, unless you know the type or check its docs or implemented traits. `FooSystems` on the other hand is much more self-descriptive in this regard, at the cost of being a bit longer to type. Ultimately, in some ways it comes down to preference and how you think of system sets. Personally, I was originally in favor of `FooSet`, but have been increasingly on the side of `FooSystems`, especially after seeing what the new names would actually look like in Avian and now Bevy. I prefer it because it usually reads better, is much more clearly related to groups of systems than `FooSet`, and overall *feels* more correct and natural to me in the long term. For these reasons, and because Alice and Cart also seemed to share a preference for it when it was previously being discussed, I propose that we adopt a `FooSystems` naming convention where applicable. ## Solution Rename Bevy's system set types to use a consistent `FooSet` naming where applicable. - `AccessibilitySystem` → `AccessibilitySystems` - `GizmoRenderSystem` → `GizmoRenderSystems` - `PickSet` → `PickingSystems` - `RunFixedMainLoopSystem` → `RunFixedMainLoopSystems` - `TransformSystem` → `TransformSystems` - `RemoteSet` → `RemoteSystems` - `RenderSet` → `RenderSystems` - `SpriteSystem` → `SpriteSystems` - `StateTransitionSteps` → `StateTransitionSystems` - `RenderUiSystem` → `RenderUiSystems` - `UiSystem` → `UiSystems` - `Animation` → `AnimationSystems` - `AssetEvents` → `AssetEventSystems` - `TrackAssets` → `AssetTrackingSystems` - `UpdateGizmoMeshes` → `GizmoMeshSystems` - `InputSystem` → `InputSystems` - `InputFocusSet` → `InputFocusSystems` - `ExtractMaterialsSet` → `MaterialExtractionSystems` - `ExtractMeshesSet` → `MeshExtractionSystems` - `RumbleSystem` → `RumbleSystems` - `CameraUpdateSystem` → `CameraUpdateSystems` - `ExtractAssetsSet` → `AssetExtractionSystems` - `Update2dText` → `Text2dUpdateSystems` - `TimeSystem` → `TimeSystems` - `AudioPlaySet` → `AudioPlaybackSystems` - `SendEvents` → `EventSenderSystems` - `EventUpdates` → `EventUpdateSystems` A lot of the names got slightly longer, but they are also a lot more consistent, and in my opinion the majority of them read much better. For a few of the names I took the liberty of rewording things a bit; definitely open to any further naming improvements. There are still also cases where the `FooSystems` naming doesn't really make sense, and those I left alone. This primarily includes system sets like `Interned<dyn SystemSet>`, `EnterSchedules<S>`, `ExitSchedules<S>`, or `TransitionSchedules<S>`, where the type has some special purpose and semantics. ## Todo - [x] Should I keep all the old names as deprecated type aliases? I can do this, but to avoid wasting work I'd prefer to first reach consensus on whether these renames are even desired. - [x] Migration guide - [x] Release notes
280 lines
10 KiB
Rust
280 lines
10 KiB
Rust
//! This module provides unsurprising default inputs to `bevy_picking` through [`PointerInput`].
|
|
//! The included systems are responsible for sending mouse and touch inputs to their
|
|
//! respective `Pointer`s.
|
|
//!
|
|
//! Because this has it's own plugin, it's easy to omit it, and provide your own inputs as
|
|
//! needed. Because `Pointer`s aren't coupled to the underlying input hardware, you can easily mock
|
|
//! inputs, and allow users full accessibility to map whatever inputs they need to pointer input.
|
|
//!
|
|
//! If, for example, you wanted to add support for VR input, all you need to do is spawn a pointer
|
|
//! entity with a custom [`PointerId`], and write a system
|
|
//! that updates its position. If you want this to work properly with the existing interaction events,
|
|
//! you need to be sure that you also write a [`PointerInput`] event stream.
|
|
|
|
use bevy_app::prelude::*;
|
|
use bevy_ecs::prelude::*;
|
|
use bevy_input::{
|
|
mouse::MouseWheel,
|
|
prelude::*,
|
|
touch::{TouchInput, TouchPhase},
|
|
ButtonState,
|
|
};
|
|
use bevy_math::Vec2;
|
|
use bevy_platform::collections::{HashMap, HashSet};
|
|
use bevy_reflect::prelude::*;
|
|
use bevy_render::camera::RenderTarget;
|
|
use bevy_window::{PrimaryWindow, WindowEvent, WindowRef};
|
|
use tracing::debug;
|
|
|
|
use crate::pointer::{
|
|
Location, PointerAction, PointerButton, PointerId, PointerInput, PointerLocation,
|
|
};
|
|
|
|
use crate::PickingSystems;
|
|
|
|
/// The picking input prelude.
|
|
///
|
|
/// This includes the most common types in this module, re-exported for your convenience.
|
|
pub mod prelude {
|
|
pub use crate::input::PointerInputPlugin;
|
|
}
|
|
|
|
/// Adds mouse and touch inputs for picking pointers to your app. This is a default input plugin,
|
|
/// that you can replace with your own plugin as needed.
|
|
///
|
|
/// [`crate::PickingPlugin::is_input_enabled`] can be used to toggle whether
|
|
/// the core picking plugin processes the inputs sent by this, or other input plugins, in one place.
|
|
///
|
|
/// This plugin contains several settings, and is added to the world as a resource after initialization.
|
|
/// You can configure pointer input settings at runtime by accessing the resource.
|
|
#[derive(Copy, Clone, Resource, Debug, Reflect)]
|
|
#[reflect(Resource, Default, Clone)]
|
|
pub struct PointerInputPlugin {
|
|
/// Should touch inputs be updated?
|
|
pub is_touch_enabled: bool,
|
|
/// Should mouse inputs be updated?
|
|
pub is_mouse_enabled: bool,
|
|
}
|
|
|
|
impl PointerInputPlugin {
|
|
fn is_mouse_enabled(state: Res<Self>) -> bool {
|
|
state.is_mouse_enabled
|
|
}
|
|
|
|
fn is_touch_enabled(state: Res<Self>) -> bool {
|
|
state.is_touch_enabled
|
|
}
|
|
}
|
|
|
|
impl Default for PointerInputPlugin {
|
|
fn default() -> Self {
|
|
Self {
|
|
is_touch_enabled: true,
|
|
is_mouse_enabled: true,
|
|
}
|
|
}
|
|
}
|
|
|
|
impl Plugin for PointerInputPlugin {
|
|
fn build(&self, app: &mut App) {
|
|
app.insert_resource(*self)
|
|
.add_systems(Startup, spawn_mouse_pointer)
|
|
.add_systems(
|
|
First,
|
|
(
|
|
mouse_pick_events.run_if(PointerInputPlugin::is_mouse_enabled),
|
|
touch_pick_events.run_if(PointerInputPlugin::is_touch_enabled),
|
|
)
|
|
.chain()
|
|
.in_set(PickingSystems::Input),
|
|
)
|
|
.add_systems(
|
|
Last,
|
|
deactivate_touch_pointers.run_if(PointerInputPlugin::is_touch_enabled),
|
|
)
|
|
.register_type::<Self>()
|
|
.register_type::<PointerInputPlugin>();
|
|
}
|
|
}
|
|
|
|
/// Spawns the default mouse pointer.
|
|
pub fn spawn_mouse_pointer(mut commands: Commands) {
|
|
commands.spawn(PointerId::Mouse);
|
|
}
|
|
|
|
/// Sends mouse pointer events to be processed by the core plugin
|
|
pub fn mouse_pick_events(
|
|
// Input
|
|
mut window_events: EventReader<WindowEvent>,
|
|
primary_window: Query<Entity, With<PrimaryWindow>>,
|
|
// Locals
|
|
mut cursor_last: Local<Vec2>,
|
|
// Output
|
|
mut pointer_events: EventWriter<PointerInput>,
|
|
) {
|
|
for window_event in window_events.read() {
|
|
match window_event {
|
|
// Handle cursor movement events
|
|
WindowEvent::CursorMoved(event) => {
|
|
let location = Location {
|
|
target: match RenderTarget::Window(WindowRef::Entity(event.window))
|
|
.normalize(primary_window.single().ok())
|
|
{
|
|
Some(target) => target,
|
|
None => continue,
|
|
},
|
|
position: event.position,
|
|
};
|
|
pointer_events.write(PointerInput::new(
|
|
PointerId::Mouse,
|
|
location,
|
|
PointerAction::Move {
|
|
delta: event.position - *cursor_last,
|
|
},
|
|
));
|
|
*cursor_last = event.position;
|
|
}
|
|
// Handle mouse button press events
|
|
WindowEvent::MouseButtonInput(input) => {
|
|
let location = Location {
|
|
target: match RenderTarget::Window(WindowRef::Entity(input.window))
|
|
.normalize(primary_window.single().ok())
|
|
{
|
|
Some(target) => target,
|
|
None => continue,
|
|
},
|
|
position: *cursor_last,
|
|
};
|
|
let button = match input.button {
|
|
MouseButton::Left => PointerButton::Primary,
|
|
MouseButton::Right => PointerButton::Secondary,
|
|
MouseButton::Middle => PointerButton::Middle,
|
|
MouseButton::Other(_) | MouseButton::Back | MouseButton::Forward => continue,
|
|
};
|
|
let action = match input.state {
|
|
ButtonState::Pressed => PointerAction::Press(button),
|
|
ButtonState::Released => PointerAction::Release(button),
|
|
};
|
|
pointer_events.write(PointerInput::new(PointerId::Mouse, location, action));
|
|
}
|
|
WindowEvent::MouseWheel(event) => {
|
|
let MouseWheel { unit, x, y, window } = *event;
|
|
|
|
let location = Location {
|
|
target: match RenderTarget::Window(WindowRef::Entity(window))
|
|
.normalize(primary_window.single().ok())
|
|
{
|
|
Some(target) => target,
|
|
None => continue,
|
|
},
|
|
position: *cursor_last,
|
|
};
|
|
|
|
let action = PointerAction::Scroll { x, y, unit };
|
|
|
|
pointer_events.write(PointerInput::new(PointerId::Mouse, location, action));
|
|
}
|
|
_ => {}
|
|
}
|
|
}
|
|
}
|
|
|
|
/// Sends touch pointer events to be consumed by the core plugin
|
|
pub fn touch_pick_events(
|
|
// Input
|
|
mut window_events: EventReader<WindowEvent>,
|
|
primary_window: Query<Entity, With<PrimaryWindow>>,
|
|
// Locals
|
|
mut touch_cache: Local<HashMap<u64, TouchInput>>,
|
|
// Output
|
|
mut commands: Commands,
|
|
mut pointer_events: EventWriter<PointerInput>,
|
|
) {
|
|
for window_event in window_events.read() {
|
|
if let WindowEvent::TouchInput(touch) = window_event {
|
|
let pointer = PointerId::Touch(touch.id);
|
|
let location = Location {
|
|
target: match RenderTarget::Window(WindowRef::Entity(touch.window))
|
|
.normalize(primary_window.single().ok())
|
|
{
|
|
Some(target) => target,
|
|
None => continue,
|
|
},
|
|
position: touch.position,
|
|
};
|
|
match touch.phase {
|
|
TouchPhase::Started => {
|
|
debug!("Spawning pointer {:?}", pointer);
|
|
commands.spawn((pointer, PointerLocation::new(location.clone())));
|
|
|
|
pointer_events.write(PointerInput::new(
|
|
pointer,
|
|
location,
|
|
PointerAction::Press(PointerButton::Primary),
|
|
));
|
|
|
|
touch_cache.insert(touch.id, *touch);
|
|
}
|
|
TouchPhase::Moved => {
|
|
// Send a move event only if it isn't the same as the last one
|
|
if let Some(last_touch) = touch_cache.get(&touch.id) {
|
|
if last_touch == touch {
|
|
continue;
|
|
}
|
|
pointer_events.write(PointerInput::new(
|
|
pointer,
|
|
location,
|
|
PointerAction::Move {
|
|
delta: touch.position - last_touch.position,
|
|
},
|
|
));
|
|
}
|
|
touch_cache.insert(touch.id, *touch);
|
|
}
|
|
TouchPhase::Ended => {
|
|
pointer_events.write(PointerInput::new(
|
|
pointer,
|
|
location,
|
|
PointerAction::Release(PointerButton::Primary),
|
|
));
|
|
touch_cache.remove(&touch.id);
|
|
}
|
|
TouchPhase::Canceled => {
|
|
pointer_events.write(PointerInput::new(
|
|
pointer,
|
|
location,
|
|
PointerAction::Cancel,
|
|
));
|
|
touch_cache.remove(&touch.id);
|
|
}
|
|
}
|
|
}
|
|
}
|
|
}
|
|
|
|
/// Deactivates unused touch pointers.
|
|
///
|
|
/// Because each new touch gets assigned a new ID, we need to remove the pointers associated with
|
|
/// touches that are no longer active.
|
|
pub fn deactivate_touch_pointers(
|
|
mut commands: Commands,
|
|
mut despawn_list: Local<HashSet<(Entity, PointerId)>>,
|
|
pointers: Query<(Entity, &PointerId)>,
|
|
mut touches: EventReader<TouchInput>,
|
|
) {
|
|
for touch in touches.read() {
|
|
if let TouchPhase::Ended | TouchPhase::Canceled = touch.phase {
|
|
for (entity, pointer) in &pointers {
|
|
if pointer.get_touch_id() == Some(touch.id) {
|
|
despawn_list.insert((entity, *pointer));
|
|
}
|
|
}
|
|
}
|
|
}
|
|
// A hash set is used to prevent despawning the same entity twice.
|
|
for (entity, pointer) in despawn_list.drain() {
|
|
debug!("Despawning pointer {:?}", pointer);
|
|
commands.entity(entity).despawn();
|
|
}
|
|
}
|