This should provide a way to iterate all the tabs and select the last
tab. The tab indicies are now zero based as any other sane index.
Follow-up-to: c5941d105f (add tabbing API)
Winit now supports tabbing identifiers, thus set that we prefer tabbing,
in particular it'll make windows tab when using the same tabbing identifiers,
which is desirable for the end users.
Some systems could resize the window immediately and we'd rather
inform the users right away if that was the case, so they could
create e.g. EGLSurface without waiting for resize, which is really
important for Wayland.
Fixes#2868.
Instead of a single `bool` indicating that a key press has occured and
no key has been released since then, we store the scancode of the last
pressed key (if it is a key that repeats when held). This fixes a bug
where pressing a new key while one is already held down will be flagged
as a repeat even though it is obviously not a repeat.
* Make iOS declared classes not use &mut
* Prepare `init` methods for not having access to &mut self
* Prepare WinitWindow methods for not having access to &mut self
* Convert a bit of WinitView's to use interior mutability
* Convert a bit more of WinitView's to use interior mutability
* Convert the rest of WinitView to use interior mutability
* Use interior mutability instead of a Mutex for the CursorState
* Use interior mutability in WinitWindowDelegate
The change to xinput2 completely disabled IME support, thus we've got
a dead keys reporting, because nothing was eating the key events
anymore, however that's not what we really need, given that not
working IME makes it impossible for some users to type.
The proper solution is to not use Xlib at all for that and rely on
xcb and its tooling around the XIM and text compose stuff, so
we'll have full control over what is getting sent to the XIM/IC or not.
Fixes#2888.
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>
