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)
Unfortunately this isn't a total removal, for two reasons:
- We still need "libc" for the Xlib XIM implementation, for locales.
- BSD requires libc to check for main-threadedness.
First one we can likely resolve in the near future, not so sure about
the second one without using some weird pthreads trick.
The utils in this module should help the users to activate the windows
they create, as well as manage activation tokens environment variables.
The API is essential for Wayland in the first place, since some
compositors may decide initial focus of the window based on whether
the activation token was during the window creation.
Fixes#2279.
Co-authored-by: John Nunley <jtnunley01@gmail.com>
Overhaul the keyboard API in winit to mimic the W3C specification
to achieve better crossplatform parity. The `KeyboardInput` event
is now uses `KeyEvent` which consists of:
- `physical_key` - a cross platform way to refer to scancodes;
- `logical_key` - keysym value, which shows your key respecting the
layout;
- `text` - the text produced by this keypress;
- `location` - the location of the key on the keyboard;
- `repeat` - whether the key was produced by the repeat.
And also a `platform_specific` field which encapsulates extra
information on desktop platforms, like key without modifiers
and text with all modifiers.
The `Modifiers` were also slightly reworked as in, the information
whether the left or right modifier is pressed is now also exposed
on platforms where it could be queried reliably. The support was
also added for the web and orbital platforms finishing the API
change.
This change made the `OptionAsAlt` API on macOS redundant thus it
was removed all together.
Co-authored-by: Artúr Kovács <kovacs.artur.barnabas@gmail.com>
Co-authored-by: Kirill Chibisov <contact@kchibisov.com>
Co-authored-by: daxpedda <daxpedda@gmail.com>
Fixes: #2631.
Fixes: #2055.
Fixes: #2032.
Fixes: #1904.
Fixes: #1810.
Fixes: #1700.
Fixes: #1443.
Fixes: #1343.
Fixes: #1208.
Fixes: #1151.
Fixes: #812.
Fixes: #600.
Fixes: #361.
Fixes: #343.
This update rewrites the winit's Wayland backend using new wayland-rs
0.30 API. This fixes long standing issue with the forward compatibility
of the wayland backend, meaning that future updates to the wayland
protocol won't break rust code anymore. like it was before when adding
new shm/enum variants into the protocol.
Fixes#2560.
Fixes#2164.
Fixes#2128.
Fixes#1760.
Fixes#725.
* Add Redox OS support
* Simplify control flow usage
* Apply more recommendations
* Update naming to indicate that Orbital is a platform
* Adjust import order
This updates the Android backend to use the android-activity crate instead
of ndk-glue. This solves a few issues:
1. The backend is agnostic of the application's choice of Activity base
class
2. Winit is no longer responsible for handling any Java synchronization
details, since these are encapsulated by the design of
android_activity
3. The backend no longer depends on global / static getters for state
such as the native_window() which puts it in a better position to
support running multiple activities within a single Android process.
4. Redraw requests are flagged, not queued, in a way that avoids taking
priority over user events (resolves#2299)
To make it possible for application crates to avoid explicitly
depending on the `android-activity` crate (and avoid version conflicts)
this re-exports the android-activity crate under:
`winit::platform::android::activity::*`
This also adds `android-native-activity` and `android-game-activity`
features that set the corresponding android-activity features.
Addresses: PR https://github.com/rust-windowing/winit/pull/1892
Addresses: PR https://github.com/rust-windowing/winit/pull/2307
Addresses: PR https://github.com/rust-windowing/winit/pull/2343
Addresses: #2293Resolves: #2299
Co-authored-by: Markus Siglreithmaier <m.siglreith@gmail.com>
Co-authored-by: Markus Siglreithmaier <m.siglreith@gmail.com>
Use the definitions that `core_foundation` exposes (almost the same, except `CFRunLoopSourceContext::perform` is not nullable, so we account for that as well).
* Remove UnownedWindow::inner_rect
* Refactor custom view to use much less `unsafe`
The compiler fence is safe to get rid of now since `interpretKeyEvents` takes `&mut self`
* Refactor Window to use much less unsafe
* Refactor NSApplication usage to have much less unsafe
* Remove cocoa dependency
* Enable `deny(unsafe_op_in_unsafe_fn)` on macOS
Also re-enable clippy `let_unit_value` lint
* Remove #[macro_use] on macOS
* Refactor window delegate to use much less unsafe
This makes Winit 0.27 compatible with crates like Wgpu 0.13 that are
using the raw_window_handle v0.4 crate and aren't able to upgrade to 0.5
until they do a new release (since it requires a semver change).
The change is intended to be self-contained (instead of pushing
the details into all the platform_impl backends) since this is only
intended to be a temporary trait implementation for backwards
compatibility that will likely be removed before the next Winit release.
Fixes#2415.
This should force the use of system libraries for Fontconfig
and freetype instead of building them with cmake if missing.
This also fixes compilation failures on nightly.
Fixes#2373.
This applies https://github.com/rust-windowing/android-ndk-rs/issues/117
on the `winit` side: Android destroys its window/surface as soon as the
user returns from [`onNativeWindowDestroyed`], and we "fixed" this on
the `ndk-glue` side by sending the `WindowDestroyed` event before
locking the window and removing it: this lock has to wait for any user
of `ndk-glue` - ie. `winit` - to give up its readlock on the window,
which is what we utilize here to give users of `winit` "time" to destroy
any resource created on top of a `RawWindowHandle`.
since we can't pass the user a `RawWindowHandle` through the
`HasRawWindowHandle` trait we have to document this case explicitly and
keep the lock alive on the `winit` side instead.
[`onNativeWindowDestroyed`]: https://developer.android.com/ndk/reference/struct/a-native-activity-callbacks#onnativewindowdestroyed
The `ndk` crate now implements [`HasRawWindowHandle` directly on
`NativeWindow`], relieving the burden to reimplement it on `winit`.
[`HasRawWindowHandle` directly on `NativeWindow`]: https://github.com/rust-windowing/android-ndk-rs/pull/274
While most compositors provide server side decorations, the GNOME
does not, and won't provide them. Also Wayland clients must render
client side decorations.
Winit was already drawing some decorations, however they were bad
looking and provided no text rendering, so the title was missing.
However this commit makes use of the SCTK external frame similar to
GTK's Adwaita theme supporting text rendering and looking similar to
other GTK applications.
Fixes#1967.
This commit brings new Ime event to account for preedit state of input
method, also adding `Window::set_ime_allowed` to toggle IME input on
the particular window.
This commit implements API as designed in #1497 for desktop platforms.
Co-authored-by: Artur Kovacs <kovacs.artur.barnabas@gmail.com>
Co-authored-by: Markus Siglreithmaier <m.siglreith@gmail.com>
Co-authored-by: Murarth <murarth@gmail.com>
Co-authored-by: Yusuke Kominami <yukke.konan@gmail.com>
Co-authored-by: moko256 <koutaro.mo@gmail.com>
* Improve web example
* Implement basic logger into the example webpage
* Repace bash script with xtask
* replace wasm-bindgen-cli with wasm-bindgen-cli-support
* refactor
* Move logic into external crate.
* Remove CI changes
* Review feedback
This reverts commit 8afeb910bd.
Reverting because this change made Pinyin input unusable
(only latin characters showed even after selecting the
desired Chinese character)
While winit was always using dlopen for opening system libs, it
provides a way now to disable dlopen feature helping with linking
on some targets.
Fixes#2037.
Kirill Chibisov