Fixes issue on Wayland due to drop order, since TLS is being dropped
after the event loop, while it shouldn't. In particular it fixes the
crash in the window_run_return example.
During the migration some logic wrt `none` decorations was lost along
the way, however we also now try to ask for client side decorations if
the user wants to disable server side decorations.
Fixes#2902.
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.
The correct handling of this setting requires to change the events
we're getting from the macOS on the fly and call `interpretKeyEvents`,
which could affect handling of the next events, meaning that we can't
provide them on `KeyEvent`.
Add named variants for physical back and forward keys which could
be found on some mice. The macOS bits may not work on all the
hardware given that apple doesn't directly support such a thing.
Co-authored-by: daxpedda <daxpedda@gmail.com>
