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.

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

Merged

Conversation

Vrixyz
Copy link
Member

@Vrixyz Vrixyz commented Jan 18, 2024

Add logical key data to KeyboardInput

Addresses an item of #11052

@Vrixyz Vrixyz added C-Enhancement A new feature A-Input Player input via keyboard, mouse, gamepad, and more labels Jan 18, 2024
@rparrett
Copy link
Contributor

It seems like this would close #11297 for me. At least the behavior between web/native on MacOS for KeyInput::logical_key(Key::Character(s)) seems predictable enough to work with. It would be great if someone could test with a non-US keyboard.

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 bevy_simple_text_input: https://github.com/rparrett/bevy_simple_text_input/blob/bevy_main/src/lib.rs#L75

///
/// ## Technical
///
/// Its values map 1 to 1 to winit's Key.
Copy link
Member

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.

Copy link
Member Author

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 ?

Copy link
Member

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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

keysym?

Copy link
Member

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.

Copy link
Member Author

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

Copy link
Member Author

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.

Copy link
Member

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.

Copy link
Member Author

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 :)

Copy link
Member

@alice-i-cecile alice-i-cecile left a 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.

@alice-i-cecile
Copy link
Member

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 would love to see an example for this, but it probably shouldn't be this PR.

@rparrett
Copy link
Contributor

rparrett commented Jan 18, 2024

I would love to see an example for this, but it probably shouldn't be this PR.

Agreed. Maybe the text_input example should be modified. It's a bit awkward because

  • using ReceivedCharacter for whitespace doesn't work consistently cross-platform (winit bug)
  • combining ReceivedCharacter and KeyboardInput is buggy because there's no way to know which event came first

Which makes ReceivedCharacter useless, practically. Personally, I'm not sure why it even needs to exist. Definitely a discussion for another GitHub issue / PR though.

Did not intend in any way to derail. This functionality is desperately needed.

crates/bevy_input/src/keyboard.rs Outdated Show resolved Hide resolved
crates/bevy_input/src/keyboard.rs Outdated Show resolved Hide resolved
crates/bevy_input/src/keyboard.rs Outdated Show resolved Hide resolved
@matiqo15 matiqo15 added the S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it label Jan 18, 2024
@alice-i-cecile
Copy link
Member

@Vrixyz lemme know when you're ready and then I'll merge. Otherwise, I'll merge Monday.

Vrixyz and others added 3 commits January 18, 2024 20:54
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>
Comment on lines 689 to 690
/// 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`].
Copy link
Member Author

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,
Copy link
Member Author

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_codeto key_physical ? Probably as a follow up, close to an existing one in #11052 ("Rename KeyCode to PhysicalKeyCode")

Copy link
Member Author

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>()
Copy link
Member Author

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.

@Vrixyz
Copy link
Member Author

Vrixyz commented Jan 18, 2024

@Vrixyz lemme know when you're ready and then I'll merge. Otherwise, I'll merge Monday.

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.

@alice-i-cecile alice-i-cecile added this pull request to the merge queue Jan 22, 2024
Merged via the queue into bevyengine:main with commit 2165793 Jan 22, 2024
26 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Input Player input via keyboard, mouse, gamepad, and more C-Enhancement A new feature S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants