You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What problem does this solve or what need does it fill?
In order to write a text input that handles things like cursor movement with arrow keys, delete, etc a user needs to process both KeyboardInput and ReceivedCharacter.
There are some issues with this:
These separate event streams are not ordered. So if e.g. Delete and A happen on the same frame, it is not possible to know which happened first. Precise input timing information #9087 could potentially help with this, but it seems far off. Multiple key events landing on the same frame is very possible / common, even.
There are platform inconsistencies with winit's KeyEvent::text, which is used to populate ReceivedCharacter. On the web, we don't generate a ReceivedCharacter event for backspace like we do on other platforms.
I am told that KeyEvent::text is meant to contain (printable characters? I still don't fully understand the distinction being drawn here), and it is considered a bug that backspace is represented in that field on Windows, Macos, and Linux. See KeyEvent::text should be None for backspace rust-windowing/winit#3381.
This means that to implement even super basic text input without a moving cursor, you still need to react to both input streams. This will continue to be true even when that platform inconsistency is fixed.
This has been an ongoing issue for me since Bevy 0.4 in my game taipo. The goal of the game is to type fast, and if backspace and other keys are processed out of order, it leads to a very bad UX. But this will also be an issue for any app providing a text input.
What solution would you like?
Provide a unified stream of events for key presses. I believe a previous draft of the winit 0.29 update had something like this, but it was dropped to make merging the update more practical.
What alternative(s) have you considered?
My initial instinct upon discovering that this inconsistency is still present after the winit 0.29 update was to fix the inconsistency by changing the behavior on the web. That didn't work out, but making our own ReceivedCharacter consistent might be possible by using Key::to_text instead of KeyEvent::text.
Additional context
This is potentially covered by one or more of 3 of the bullet points in the "Winit 0.29 follow up."
The text was updated successfully, but these errors were encountered:
rparrett
changed the title
Provide a way to get characters for all keypress events
Provide a unified stream of key press events with character equivalents
Jan 11, 2024
What problem does this solve or what need does it fill?
In order to write a text input that handles things like cursor movement with arrow keys, delete, etc a user needs to process both
KeyboardInput
andReceivedCharacter
.There are some issues with this:
These separate event streams are not ordered. So if e.g.
Delete
andA
happen on the same frame, it is not possible to know which happened first. Precise input timing information #9087 could potentially help with this, but it seems far off. Multiple key events landing on the same frame is very possible / common, even.There are platform inconsistencies with winit's
KeyEvent::text
, which is used to populateReceivedCharacter
. On the web, we don't generate aReceivedCharacter
event for backspace like we do on other platforms.I am told that
KeyEvent::text
is meant to contain (printable characters? I still don't fully understand the distinction being drawn here), and it is considered a bug that backspace is represented in that field on Windows, Macos, and Linux. SeeKeyEvent::text
should beNone
for backspace rust-windowing/winit#3381.This means that to implement even super basic text input without a moving cursor, you still need to react to both input streams. This will continue to be true even when that platform inconsistency is fixed.
This has been an ongoing issue for me since Bevy 0.4 in my game taipo. The goal of the game is to type fast, and if backspace and other keys are processed out of order, it leads to a very bad UX. But this will also be an issue for any app providing a text input.
What solution would you like?
Provide a unified stream of events for key presses. I believe a previous draft of the winit 0.29 update had something like this, but it was dropped to make merging the update more practical.
What alternative(s) have you considered?
My initial instinct upon discovering that this inconsistency is still present after the winit 0.29 update was to fix the inconsistency by changing the behavior on the web. That didn't work out, but making our own
ReceivedCharacter
consistent might be possible by usingKey::to_text
instead ofKeyEvent::text
.Additional context
This is potentially covered by one or more of 3 of the bullet points in the "Winit 0.29 follow up."
The text was updated successfully, but these errors were encountered: