Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add support for reflection to remaining input types #6223

Closed
TehPers opened this issue Oct 10, 2022 · 3 comments
Closed

Add support for reflection to remaining input types #6223

TehPers opened this issue Oct 10, 2022 · 3 comments
Labels
A-Input Player input via keyboard, mouse, gamepad, and more A-Reflection Runtime information about types C-Usability A targeted quality-of-life change that makes Bevy easier to use

Comments

@TehPers
Copy link
Contributor

TehPers commented Oct 10, 2022

What problem does this solve or what need does it fill?

This allows users to access the input types via reflection, which could be useful for scripting, debugging (via bevy-inspector-egui for example), etc.

What solution would you like?

Add #[derive(Reflect, FromReflect)] to input types and register their types in the InputPlugin. Also add #[reflect(Traits)] for relevant traits to the types.

Common:

  • ButtonState

Keyboard:

  • KeyCode (register_type only, since it doesn't seem to be done in the InputPlugin)
  • KeyboardInput

Mouse:

  • MouseButton
  • MouseButtonInput
  • MouseScrollUnit
  • MouseMotion
  • MouseWheel

Gamepads:

  • GamepadButtonType
  • GamepadAxisType
  • Gamepad
  • GamepadButton
  • GamepadAxis
  • GamepadEventType
  • GamepadEvent

Touch:

  • TouchPhase
  • ForceTouch
  • TouchInput
  • Touch (maybe?)
  • Touches (maybe?)

For most (if not all) of these types, it's just a matter of adding #[derive(Reflect, FromReflect)] to the type and reflecting the relevant traits.

What alternative(s) have you considered?

Users can recreate these types (with reflection support) in their own projects and create a system which maps the input types, but this step seems unnecessary. (This is different than mapping raw inputs to actions, it's mapping raw inputs to raw inputs.)

Additional context

KeyCode already implements Reflect and FromReflect. The only change needed there is to add .register_type::<KeyCode>() in the InputPlugin.
@TehPers TehPers added C-Feature A new feature, making something new possible S-Needs-Triage This issue needs to be labelled labels Oct 10, 2022
@alice-i-cecile alice-i-cecile added A-Input Player input via keyboard, mouse, gamepad, and more C-Usability A targeted quality-of-life change that makes Bevy easier to use A-Reflection Runtime information about types and removed C-Feature A new feature, making something new possible S-Needs-Triage This issue needs to be labelled labels Oct 10, 2022
@alice-i-cecile
Copy link
Member

You'll want most of the window events too to round this out.

@TehPers
Copy link
Contributor Author

TehPers commented Oct 11, 2022

I'll open a PR for the input types. I can create a separate PR for window events too, unless you think that should be included in the input types PR. I think separating makes sense because they are two different crates but either way works for me.

@alice-i-cecile
Copy link
Member

I'm fine with either approach.

This was referenced Oct 11, 2022
Closed
Closed
@bors bors bot closed this as completed in 2023ce6 Oct 26, 2022
james7132 pushed a commit to james7132/bevy that referenced this issue Oct 28, 2022
@TehPers @james7132
Derive Reflect + FromReflect for input types (bevyengine#6232)
4cefe57 
# Objective

Adds support for reflecting many more of the input types. This allows those types to be used via scripting, `bevy-inspector-egui`, etc. These types are registered by the `InputPlugin` so that they're automatically available to anyone who wants to use them 

Closes bevyengine#6223 

## Solution

Many types now have `#[derive(Reflect, FromReflect)]` added to them in `bevy_input`. Additionally, `#[reflect(traits...)]` has been added for applicable traits to the types.

This PR does not add reflection support for types which have private fields. Notably, `Touch` and `Touches` don't implement `Reflect`/`FromReflect`.

This adds the "glam" feature to the `bevy_reflect` dependency for package `bevy_input`. Since `bevy_input` transitively depends on `glam` already, all this brings in are the reflection `impl`s.

## Migration Guide

- `Input<T>` now implements `Reflect` via `#[reflect]` instead of `#[reflect_value]`. This means it now exposes its private fields via the `Reflect` trait rather than being treated as a value type. For code that relies on the `Input<T>` struct being treated as a value type by reflection, it is still possible to wrap the `Input<T>` type with a wrapper struct and apply `#[reflect_value]` to it.
  - As a reminder, private fields exposed via reflection are not subject to any stability guarantees.
---

## Changelog

Added
- Implemented `Reflect` + `FromReflect` for many input-related types. These types are automatically registered when adding the `InputPlugin`.
bors bot pushed a commit that referenced this issue Dec 9, 2022
@TehPers
Derive Reflect + FromReflect for window event types (#6235)
a5d70b8 
# Objective

The window event types currently don't support reflection. This PR adds support to them (as requested [here](#6223 (comment))).

## Solution

Implement `Reflect` + `FromReflect` for window event types. Relevant traits are also being reflected with `#[reflect(...)]` attributes.

Additionally, this PR derives `Reflect` + `FromReflect` for `WindowDescriptor` and the types it depends on so that `CreateWindow` events can be fully manipulated through reflection.

Finally, this PR adds `FromReflect` for `PathBuf` as a value type, which is needed for `FileDragAndDrop`.

This adds the "glam" feature to the `bevy_reflect` dependency for package `bevy_window`. Since `bevy_window` transitively depends on `glam` already, all this brings in are the reflection `impl`s.

## Open questions

Should `app.register_type::<PathBuf>();` be moved to `CorePlugin`? I added it to `WindowPlugin` because that's where it's used and `CorePlugin` doesn't seem to register all the missing std types, but it would also make sense in `CorePlugin` I believe since it's a commonly used type.

---

## Changelog

Added:
- Implemented `Reflect` + `FromReflect` for window events and related types. These types are automatically registered when adding the `WindowPlugin`.
alradish pushed a commit to alradish/bevy that referenced this issue Jan 22, 2023
@TehPers @alradish
Derive Reflect + FromReflect for window event types (bevyengine#6235
18c56d7 
)

# Objective

The window event types currently don't support reflection. This PR adds support to them (as requested [here](bevyengine#6223 (comment))).

## Solution

Implement `Reflect` + `FromReflect` for window event types. Relevant traits are also being reflected with `#[reflect(...)]` attributes.

Additionally, this PR derives `Reflect` + `FromReflect` for `WindowDescriptor` and the types it depends on so that `CreateWindow` events can be fully manipulated through reflection.

Finally, this PR adds `FromReflect` for `PathBuf` as a value type, which is needed for `FileDragAndDrop`.

This adds the "glam" feature to the `bevy_reflect` dependency for package `bevy_window`. Since `bevy_window` transitively depends on `glam` already, all this brings in are the reflection `impl`s.

## Open questions

Should `app.register_type::<PathBuf>();` be moved to `CorePlugin`? I added it to `WindowPlugin` because that's where it's used and `CorePlugin` doesn't seem to register all the missing std types, but it would also make sense in `CorePlugin` I believe since it's a commonly used type.

---

## Changelog

Added:
- Implemented `Reflect` + `FromReflect` for window events and related types. These types are automatically registered when adding the `WindowPlugin`.
ItsDoot pushed a commit to ItsDoot/bevy that referenced this issue Feb 1, 2023
@TehPers @ItsDoot
Derive Reflect + FromReflect for input types (bevyengine#6232)
b9e8521 
# Objective

Adds support for reflecting many more of the input types. This allows those types to be used via scripting, `bevy-inspector-egui`, etc. These types are registered by the `InputPlugin` so that they're automatically available to anyone who wants to use them 

Closes bevyengine#6223 

## Solution

Many types now have `#[derive(Reflect, FromReflect)]` added to them in `bevy_input`. Additionally, `#[reflect(traits...)]` has been added for applicable traits to the types.

This PR does not add reflection support for types which have private fields. Notably, `Touch` and `Touches` don't implement `Reflect`/`FromReflect`.

This adds the "glam" feature to the `bevy_reflect` dependency for package `bevy_input`. Since `bevy_input` transitively depends on `glam` already, all this brings in are the reflection `impl`s.

## Migration Guide

- `Input<T>` now implements `Reflect` via `#[reflect]` instead of `#[reflect_value]`. This means it now exposes its private fields via the `Reflect` trait rather than being treated as a value type. For code that relies on the `Input<T>` struct being treated as a value type by reflection, it is still possible to wrap the `Input<T>` type with a wrapper struct and apply `#[reflect_value]` to it.
  - As a reminder, private fields exposed via reflection are not subject to any stability guarantees.
---

## Changelog

Added
- Implemented `Reflect` + `FromReflect` for many input-related types. These types are automatically registered when adding the `InputPlugin`.
ItsDoot pushed a commit to ItsDoot/bevy that referenced this issue Feb 1, 2023
@TehPers @ItsDoot
Derive Reflect + FromReflect for window event types (bevyengine#6235
a142797 
)

# Objective

The window event types currently don't support reflection. This PR adds support to them (as requested [here](bevyengine#6223 (comment))).

## Solution

Implement `Reflect` + `FromReflect` for window event types. Relevant traits are also being reflected with `#[reflect(...)]` attributes.

Additionally, this PR derives `Reflect` + `FromReflect` for `WindowDescriptor` and the types it depends on so that `CreateWindow` events can be fully manipulated through reflection.

Finally, this PR adds `FromReflect` for `PathBuf` as a value type, which is needed for `FileDragAndDrop`.

This adds the "glam" feature to the `bevy_reflect` dependency for package `bevy_window`. Since `bevy_window` transitively depends on `glam` already, all this brings in are the reflection `impl`s.

## Open questions

Should `app.register_type::<PathBuf>();` be moved to `CorePlugin`? I added it to `WindowPlugin` because that's where it's used and `CorePlugin` doesn't seem to register all the missing std types, but it would also make sense in `CorePlugin` I believe since it's a commonly used type.

---

## Changelog

Added:
- Implemented `Reflect` + `FromReflect` for window events and related types. These types are automatically registered when adding the `WindowPlugin`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-Input Player input via keyboard, mouse, gamepad, and more A-Reflection Runtime information about types C-Usability A targeted quality-of-life change that makes Bevy easier to use
Projects
Reflection
Status: Done
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

[Merged by Bors] - Derive Reflect + FromReflect for input types TehPers/bevy
2 participants
@TehPers @alice-i-cecile