-
-
Notifications
You must be signed in to change notification settings - Fork 3.8k
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.
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
Add logical key data to KeyboardInput #11400
Add logical key data to KeyboardInput #11400
Conversation
It seems like this would close #11297 for me. At least the behavior between web/native on MacOS for I am still sort of baffled by the myriad of ways of getting a character from a winit key event, so I hope I'm doing this correctly. I'm testing in this branch of |
/// | ||
/// ## Technical | ||
/// | ||
/// Its values map 1 to 1 to winit's Key. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doc link here would be useful.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can't really "doc link", not to the exact type, because we could rely on another backend. This note is more for contributors to understand where this is coming from. I think a link to winit would be useful but maybe difficult to maintain ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh hmm, true. I suppose this is the best we can readily do.
/// different values on different platforms, which is one of the reasons this is a per-platform | ||
/// enum. | ||
/// | ||
/// This enum is primarily used to store raw keysym when Winit doesn't map a given native logical |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
keysym?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe it's short for key symbol.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Those descriptions are coming mostly from winit, I'm not sure referring to them as keysym helps much the user indeed. A google search on that term doesn't respond with a clear description, so I assume it's a vague term for referring to key codes, or logical key code names.
I'm not opposed to remove the term. Or maybe bikeshed that in another issue
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@alice-i-cecile another question on that line is the reference to winit which we should probably avoid within bevy_input in favor of "window backend" or equivalent.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, "windowing backend" is slightly better.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
at the same time, I'm curious how many users don't use winit ; blurring the line of the dependency to winit comes at a price of increased complexity: the user has to understand what is the "windowing backend".
It can be argued it's a "small complexity", or an "implementation detail", but I hate when I have to jump through a lot of "soft references", I'll consider this "extreme abstraction" shadowing winit controversial.
It's listed in the todo on #11052 so this discussion will come again :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A couple of doc suggestions but nothing blocking.
I would love to see an example for this, but it probably shouldn't be this PR. |
Agreed. Maybe the
Which makes Did not intend in any way to derail. This functionality is desperately needed. |
@Vrixyz lemme know when you're ready and then I'll merge. Otherwise, I'll merge Monday. |
Co-authored-by: Mateusz Wachowiak <mateusz_wachowiak@outlook.com>
Co-authored-by: Mateusz Wachowiak <mateusz_wachowiak@outlook.com>
Co-authored-by: Mateusz Wachowiak <mateusz_wachowiak@outlook.com>
crates/bevy_input/src/keyboard.rs
Outdated
/// It is used as the generic `T` value of an [`Input`] to create a `Res<Input<Key>>`. | ||
/// The resource values are mapped to the current layout of the keyboard and correlate to a [`KeyCode`]. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is wrong, it's only used in KeyboardInput
.
I wanted to support that use case but decided to remove it there: 9c7a452#diff-175a1b1cfe0a099d4b8927aff78925ab491b7f48c14a0ad99ad1f34c688e3e51.
More insights here: Vrixyz#3
TL;DR: adding support for reliable is_released(a key)
after is_pressed(same key)
has fired is controversial at best.
pub key_code: KeyCode, | ||
/// The logical key of the input | ||
pub logical_key: Key, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe key_logical
? so nomenclature is similar for similar properties.
And rename key_code
to key_physical
? Probably as a follow up, close to an existing one in #11052 ("Rename KeyCode to PhysicalKeyCode")
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
or I guess we'll probably rename key_code
to physical_key
.
I just like the similar starting keystroks for similar properties, because it's autocompletion friendly, but I won't insist on it. (especially since winit uses physical_key
and logical_key
, so LGTM for now.
@@ -114,7 +114,10 @@ impl Plugin for InputPlugin { | |||
|
|||
// Register keyboard types | |||
app.register_type::<KeyboardInput>() | |||
.register_type::<KeyCode>(); | |||
.register_type::<KeyCode>() | |||
.register_type::<NativeKeyCode>() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a tiny bit out of scope, but I guess it's alright.
Thanks @alice-i-cecile ! I think I'm done with it now, I left a few self-reviews to guide more discussion if need be. |
Add logical key data to KeyboardInput
Addresses an item of #11052