44ad3bf62b
# Objective `bevy_ecs`'s `system` module is something of a grab bag, and *very* large. This is particularly true for the `system_param` module, which is more than 2k lines long! While it could be defensible to put `Res` and `ResMut` there (lol no they're in change_detection.rs, obviously), it doesn't make any sense to put the `Resource` trait there. This is confusing to navigate (and painful to work on and review). ## Solution - Create a root level `bevy_ecs/resource.rs` module to mirror `bevy_ecs/component.rs` - move the `Resource` trait to that module - move the `Resource` derive macro to that module as well (Rust really likes when you pun on the names of the derive macro and trait and put them in the same path) - fix all of the imports ## Notes to reviewers - We could probably move more stuff into here, but I wanted to keep this PR as small as possible given the absurd level of import changes. - This PR is ground work for my upcoming attempts to store resource data on components (resources-as-entities). Splitting this code out will make the work and review a bit easier, and is the sort of overdue refactor that's good to do as part of more meaningful work. ## Testing cargo build works! ## Migration Guide `bevy_ecs::system::Resource` has been moved to `bevy_ecs::resource::Resource`.
35 lines
1.2 KiB
Rust
35 lines
1.2 KiB
Rust
use winit::monitor::MonitorHandle;
|
|
|
|
use bevy_ecs::{entity::Entity, resource::Resource};
|
|
|
|
/// Stores [`winit`] monitors and their corresponding entities
|
|
///
|
|
/// # Known Issues
|
|
///
|
|
/// On some platforms, physically disconnecting a monitor might result in a
|
|
/// panic in [`winit`]'s loop. This will lead to a crash in the bevy app. See
|
|
/// [13669] for investigations and discussions.
|
|
///
|
|
/// [13669]: https://github.com/bevyengine/bevy/pull/13669
|
|
#[derive(Resource, Debug, Default)]
|
|
pub struct WinitMonitors {
|
|
/// Stores [`winit`] monitors and their corresponding entities
|
|
// We can't use a `BtreeMap` here because clippy complains about using `MonitorHandle` as a key
|
|
// on some platforms. Using a `Vec` is fine because we don't expect to have a large number of
|
|
// monitors and avoids having to audit the code for `MonitorHandle` equality.
|
|
pub(crate) monitors: Vec<(MonitorHandle, Entity)>,
|
|
}
|
|
|
|
impl WinitMonitors {
|
|
pub fn nth(&self, n: usize) -> Option<MonitorHandle> {
|
|
self.monitors.get(n).map(|(monitor, _)| monitor.clone())
|
|
}
|
|
|
|
pub fn find_entity(&self, entity: Entity) -> Option<MonitorHandle> {
|
|
self.monitors
|
|
.iter()
|
|
.find(|(_, e)| *e == entity)
|
|
.map(|(monitor, _)| monitor.clone())
|
|
}
|
|
}
|