Keyboard Input 2.0

[maroider]

• Tested on all platforms changed
• Added an entry to CHANGELOG.md if knowledge of this change could be valuable to users
• Updated documentation to reflect any user-facing changes, including notes of platform-specific behavior
• Created or updated an example program if it would help users understand this functionality
• Updated feature matrix, if new features were added or implemented

Sorry again for taking so long to get to this point, but @ArturKovacs and I are finally done rewriting the git history and integrating all our separate branches into one branch with one commit per backend, and rebasing the resulting branch on top of master. I'll make sure to keep this continuously rebased on master until it is merged.

While this branch should largely work as-is, there are a couple of things I think are worth addressing:

1. The meaning of the Meta/Super enum variants may not be consistent across backends.
2. I'm no longer all that happy with Key::Character(&'static str) (i.e. leaking key strings and stuffing them in a HashMap). I intend to summarize the benefits and drawbacks of various alternatives shortly (so please don't immediately dive into bike-shedding this), but I'd like to get this PR before I fall asleep.
3. The X11 backend could potentially be ill-behaved WRT keyboard shortcuts provided by desktop environments. I haven't tested this myself, but it's a potential issue I seem to recall encountering when trudging through documentation.
4. The Android backend pulls a somewhat icky trick with pointer casts. It would be nice if android_activity could deref KeyEvent to the ndk struct it wraps on the NativeActivity backend, similar to how the struct works on the GameActivity backend.
5. Wiring up Window::reset_dead_keys on the Linux backend without using a static AtomicBool would be a nice-to-have.
6. xkbcommon-dl needs a new release with changes we depend on.
7. Between when the main implementation work was done and now, we've gained a Redox backend. As such, we ought to get the Redox backend working on this branch.

Closes #1888, #1890, and #1932.

[madsmtm]

Yay, you two are wonderful and we love you!

Points 1 to 5

In the spirit of wanting to get this merged as soon as possible so that this giant change doesn't go out of sync again, I propose that all of these are non-important, and can be resolved in future PRs instead.

6. xkbcommon-dl needs a new release with changes we depend on.

The git dependency is fine until we want to do a release.

7. Between when the main implementation work was done and now, we've gained a Redox backend. As such, we ought to get the Redox backend working on this branch.

Same philosophy, I don't think we necessarily need to block this PR on that (sorry @jackpot51, but Redox is lower on users priority list than proper keyboard handling. Still something we'd need to resolve before the next release of course!)

---

I reviewed the macOS implementation, with mostly a focus on the unsafe stuff, I kinda lost track of things inside create_key_event (since I'm not nearly as qualified as y'all in determining the correct behaviour). But it looks pretty good in that regard, only a few minor things that I noted down for reference, but can be resolved later. @ArturKovacs I can make my nitpick changes myself if you'd like?

[madsmtm]

Nit: This seems like it should be a pub(crate) fn on KeyLocation in src/keyboard.rs instead (since it's also used e.g. in the Wayland backend).

[ArturKovacs]

Be careful that if you add this change, it should go in a separate commmit that's a fixup for the API changes commit.
✅

[maroider]

(since it's also used e.g. in the Wayland backend).

There's only really a similar function in the Android backend (with the same name to boot). The X11 and Wayland backends do share a function called keysym_to_location, however.

[ArturKovacs]

I think this should be public regardless, because it might be a functionality that winit users want to use. I think it would probably be best to add this as a method of KeyCode so people can write code.get_location()

[ArturKovacs]

@madsmtm @maroider is it okay if I add this get_location function as a public method on KeyCode? I mean something like:

impl KeyCode {
   pub fn get_location(&self) -> KeyLocation {
       match self {
           // ...
       }
   }
}

[madsmtm]

Nit: I'd much rather have this inside flagsChanged: instead of it being merged with the other callers of update_modifiers (since then it's easier to verify that e.g. code_to_location doesn't hit the unreachable! case)

[ArturKovacs]

I don't actually see why that would be better, but I trust you on this one.
✅

[daxpedda]

Currently on Web there is a bug that e.g. if you press left and right shift at the same time, but only release right, it will report that no modifier keys are now active, even though you are still holding down the left shift key.
This happens with any modifier key.

I will provide a fix tomorrow!

[kchibisov]

Currently on Web there is a bug that e.g. if you press left and right shift at the same time, but only release right, it will report that no modifier keys are now active, even though you are still holding down the left shift key.
This happens with any modifier key.

I have a feeling that it's the issue with your system given that you have the same issue on Web and X11. On X11 we get the modifiers out of the event we don't track any of the keys.

On my system I can't repro the issue you're talking about. Maybe you looked at the event logs wrong though, lifting one modifier shouldn't result in modifiers changed event.

[daxpedda]

I have a feeling that it's the issue with your system given that you have the same issue on Web and X11. On X11 we get the modifiers out of the event we don't track any of the keys.

On my system I can't repro the issue you're talking about. Maybe you looked at the event logs wrong though, lifting one modifier shouldn't result in modifiers changed event.

We cleared this up on Matrix, it was a misunderstanding. This is not a bug.

[kchibisov]

Thanks to everyone involved into this work.

[ArturKovacs]

Working on this changeset has been a major part of my life in 2020 and in 2021 - it has brought joy, frustration, excitement and everything in-between. This getting mered is almost like a dream coming true to me. I'd like to thank everybody that put effort into moving this forward.

There were many who contributed, but in particular I would like to highlight @maroider who joined me at the beggining in implementing the API and put a huge amount of effort into X11, Wayland, and the Web implementations. I would also like to give a big thanks to @kchibisov who picked up our work, took care of the rough edges and pushed this over the finish line.

♥