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>
Even when the protocol explicitly tells to send proper UTF-8
boundaries for cursor, some IMEs don't do that, so sanity check
them before sending downstream.
* MacOS: set value for `accepts_first_mouse`
* Update CHANGELOG and FEATURES
* Field doesn't need to be public
* Convert `bool` to `BOOL`
* Fix formatting
* Move flag from window state to view instance
* Feedback from PR
* Fix changelog location
* Disable scrolling on web by default but provide method in builder to enable it
* rename enable_web_scroll -> enable_web_page_scroll
* move enable_web_page_scroll into prevent_default option
* final approach
* Mark prevent_default change as breaking
Co-authored-by: Mads Marquart <mads@marquart.dk>
- Pass WM_SYSKEYDOWN to DefWindowProc
- Avoid intercepting WM_SYSCHAR to allow ALT+Space to work: removes ReceivedCharacter events for alt+keypress
- Intercept WM_MENUCHAR to disable bell sound
On Waylnad when asking for redraw before `MainEventsCleared`
would result for redraw being send on the next event loop tick,
which is not expectable given that it must be delivered on the same
event loop tick.
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.
To be more consistent with mobile platforms this updates the Windows,
macOS, Wayland, X11 and Web backends to all emit a Resumed event
immediately after the initial `NewEvents(StartCause::Init)` event.
The documentation for Suspended and Resumed has also been updated
to provide general recommendations for how to handle Suspended and
Resumed events in portable applications as well as providing
Android and iOS specific details.
This consistency makes it possible to write applications that lazily
initialize their graphics state when the application resumes without
any platform-specific knowledge. Previously, applications that wanted
to run on Android and other systems would have to maintain two,
mutually-exclusive, initialization paths.
Note: This patch does nothing to guarantee that Suspended events will
be delivered. It's still reasonable to say that most OSs without a
formal lifecycle for applications will simply never "suspend" your
application. There are currently no known portability issues caused
by not delivering `Suspended` events consistently and technically
it's not possible to guarantee the delivery of `Suspended` events if
the OS doesn't define an application lifecycle. (app can always be
terminated without any kind of clean up notification on most
non-mobile OSs)
Fixes#2185.
Co-authored-by: Marijn Suijten <marijns95@gmail.com>
Co-authored-by: Markus Røyset <maroider@protonmail.com>
winit's notion of "focus" is very simple; you're either focused or not.
However, Windows has both notions of focused window and active window
and paying attention only to WM_SETFOCUS/WM_KILLFOCUS can cause a window
to believe the user is interacting with it when they're not. (this
manifests when a user switches to another application between when a
winit application starts and it creates its first window)
