By removing `NamedKey::Space` and rename "super" key to "meta".
- `NamedKey::Space` is not in the spec, and doesn't make sense to
special-case. We use `Key::Character("")` instead..
I've added an extra check on the Windows backend, to ensure that the code
functionally works the same before and after. Whether that check is
desirable or not can be figured out later.
- "super" is inconsistent with the W3C spec, and while it's arguably not the
best name, it's worse that Winit is diverging and choosing a different name.
List of renamings:
- `KeyCode::SuperLeft` -> `KeyCode::MetaLeft`
- `KeyCode::SuperRight` -> `KeyCode::MetaRight`
- `KeyCode::Meta` -> `KeyCode::Super`
- `NamedKey::Meta` -> `NamedKey::Super`
- `NamedKey::Super` -> `NamedKey::Meta`
- `ModifiersState::SUPER` -> `ModifiersState::META` (deprecated)
- `ModifiersState::super_key` -> `ModifiersState::meta_key`
- `ModifiersKeys::LSUPER` -> `ModifiersKeys::LMETA`
- `ModifiersKeys::RSUPER` -> `ModifiersKeys::RMETA`
Tracing is a modern replacement for the log crate that allows for
annotating log messages with the function that they come from.
Signed-off-by: John Nunley <dev@notgull.net>
Closes: #3482
Split `Key` into clear categories, like `Named`, `Dead`, Character`, `Unidentified`
removing the `#[non_exhaustive]` from the `Key` itself.
Similar action was done for the `KeyCode`.
Fixes: #2995
Co-authored-by: Kirill Chibisov <contact@kchibisov.com>
Up until now the Android backend has been directly mapping key codes
which essentially just represent the "physical" cap of the key (quoted
since this also related to virtual keyboards).
Since we didn't account for any meta keys either it meant the backend
only supported a 1:1 mapping from key codes, which only covers a tiny
subset of characters. For example you couldn't type a colon since
there's no keycode for that and we didn't try and map Shift+Semicolon
into a colon character.
This has been tricky to support because the `NativeActivity` class doesn't
have direct access to the Java `KeyEvent` object which exposes a more
convenient `getUnicodeChar` API.
It is now possible to query a `KeyCharcterMap` for the device associated
with a `KeyEvent` via the `AndroidApp::device_key_character_map` API
which provides a binding to the SDK `KeyCharacterMap` API in Java:
https://developer.android.com/reference/android/view/KeyCharacterMap
This is effectively what `getUnicodeChar` is implemented based on and is
a bit more general purpose.
`KeyCharacterMap` lets us map a key_code + meta_state from a `KeyEvent`
into either a unicode character or dead key accent that can be combined
with the following key. This mapping is done based on the user's chosen
layout for the keyboard.
To enable support for key character maps the
`AndroidApp::input_events()` API was replaced by
`AndroidApp::input_events_iter()` which returns a (lending) iterator for
events. This was changed because the previous design made it difficult
to allow other AndroidApp APIs to be used while iterating events (mainly
because AndroidApp held a lock over the backend during iteration)
The recent overhaul of the keyboard API broke keyboard input on Android.
The recent keyboard changes also broke building against the
game-activity backend of android-activity because it was assumed that
the backend is based on the NDK input API which isn't the case with
with game-activity since it doesn't use the InputQueue API from the NDK.
Any alphanumeric keycodes were being mapped to `Unidentified` Keys
which meant even crude keyboard input support was broken.
We do need to expose `getUnicodeChar` (or the ability to look
up characters based on the current character map and modifiers) but
for now we should at least map alphanumeric keycodes to `Key::Character`
for basic interim support of virtual keyboards.
This moves all the keycode mapping into a separate `keycodes.rs` file
to reduce clutter.
This adds back the mapping from Android key codes to Winit key codes
that we had before the keyboard API overhaul.
Android activity does expose scan codes but key codes currently seem
like the more appropriate mapping to Winit physical key codes.
This removes the gnarly, unsafe cfg() guarded digging into
'native-activity' and 'game-activity' specific implementation details. I
never intended to expose these details in the public API and really
hope to avoid there being a release of Winit that would depend on this.
I'm also hoping/considering if I can get away with sealing this without
necessarily requiring a semver breaking release of android_activity
since this absolutely should never have been possible, and can probably
safely assume this was the only code in the wild that has briefly done
this.
I'm also a bit unclear as to what led to doing this. There is a
`.key_code()` and `.scan_code()` getter and we even already accessed the
keycode in the Android backend so I'm not sure how those APIs were missed.
