Introduced in https://github.com/rust-windowing/winit/pull/2479; turns out the definitions were not entirely equal, the `kCFRunLoopEntry` that we were using previously was defined as `0` while the correct value is `1` (which meant the `unimplemented!()` branch suddenly started triggering)
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
* 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>
* Begin abstraction over AppKit
* Clean up NSApplication delegate declaration
* Clean up NSApplication override declaration
* Clean up NSWindow delegate declaration
* Clean up NSWindow override declaration
* Clean up NSView delegate declaration
- 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.
* Add CODEOWNERS file
This makes it very clear when you're stepping down from the post as a maintainer, and makes it clear for users who is expected to review their PR
* Fix grammar
* Make @kchibisov receive pings for the X11 platform
* Fix typo
Co-authored-by: Kirill Chibisov <contact@kchibisov.com>
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>
