iOS parts of #3758.
This allows the user to override the application delegate themselves,
which opens several doors for customization that were previously closed.
To do this, we use notifications instead of a top-level application
delegate.
One effect of not providing an application delegate on iOS is that we no
longer act as-if the application successfully open all URLs there.
This is a breaking change, although unlikely to matter in practice,
since the return value of `application:didFinishLaunchingWithOptions:`
is seldom used by the system (and this is likely the preferred behaviour
anyhow).
This implements basic iOS IME support (typing, backspace, support for emojis
etc but no autocomplete or copy / paste menu).
Co-authored-by: Mads Marquart <mads@marquart.dk>
Previous version used [`SetTimer`] with `GetMessageW` for waiting.
The downside of UI timers like ones created by `SetTimer`,
is that they may be late by up to 15-16 ms.
To fix this behaviour, I added use of high resolution timers created by
[`CreateWaitableTimerExW`] with the flag
`CREATE_WAITABLE_TIMER_HIGH_RESOLUTION`.
In my previous experience, waiting on such timers have precision of
roundly 0.5 ms which is the best available on Windows at the moment. I
use [`MsgWaitForMultipleObjectsEx`] to wait simultaneously for both
timer and newly arriving events.
Unfortunately, high resolution timers are available only since Windows
10 1803. However:
1. Win 10 is already getting to the end of support, like all previous
versions, so it is OK to rely on APIs introduced in it;
2. I use `dwMilliseconds` parameter of `MsgWaitForMultipleObjectsEx` as
a fallback. It should perform not worse compared to waiting for
events from `SetTimer`.
I also refactored code to remove event dispatching from function
responsible for waiting for events. This provides more clear separations
of concern and avoids unnecessary duplication of dispatching logic.
After [review] from @rib, I also moved the waiting itself from
`wait_for_messages` method to separate function, so it is clearly seen
that `wait_for_messages` do 3 things: notify app that we about to wait,
wait, notify that we have new events.
I have tested behaviour using a egui app with Vulkan rendering with
`VK_PRESENT_MODE_IMMEDIATE_KHR`, and older version consistently have
twice less FPS than requested (e.g. 30 FPS when limit is 60 and 60 FPS
when limit is 120) while newer version works more correctly (almost
always 60 FPS when limit is 60, and only 5-10 frames missing when FPS is
set to 120 or more).
Fixes https://github.com/rust-windowing/winit/issues/1610
[`CreateWaitableTimerExW`]: https://learn.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-createwaitabletimerexw
[`MsgWaitForMultipleObjectsEx`]: https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-msgwaitformultipleobjectsex
[`SetTimer`]: https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-settimer
[review]: https://github.com/rust-windowing/winit/pull/3950#discussion_r1800184479
This new implementation uses:
- The NSAppearanceCustomization protocol for retrieving the appearance
of the window, instead of using the application-wide
`-[NSApplication effectiveAppearance]`.
- Key-Value observing for observing the `effectiveAppearance` to compute
the `ThemeChanged` event, instead of using the undocumented
`AppleInterfaceThemeChangedNotification` notification.
This also fixes `WindowBuilder::with_theme` not having any effect, and
the conversion between `Theme` and `NSAppearance` is made a bit more
robust.
Not using `NSColor::clearColor()` results in Quartz thinking that the
window is not transparent at all, which results in artifacts.
However, not setting the `windowBackgroundColor` in
`Window::set_transparent` results in border not properly rendered.
Fixes: 94664ff687 (Don't set the background color)
* Use AppKit's internal queuing mechanisms
This allows events to be queued in a more consistent order, they're now
interleaved with events that we handle immediately (like redraw events),
instead of being handled afterwards.
* Only queue events if necessary
This makes the call stack / backtraces easier to understand whenever
possible, and generally improves upon the order in which events are
delivered.
Setting the background color changes how the window title bar appears,
which is something that the application should customize itself if it
wants this behaviour (and also, it wasn't set when calling
`set_transparent`, so the behaviour wasn't consistent).
Changes relevant to Winit:
- `icrate` has been deprecated in favour of separate crates per
framework, in our case `objc2-foundation` and `objc2-app-kit` (and in
the future `objc2-ui-kit` on iOS).
- Moved `MainThreadMarker::run_on_main` to free-standing function
`run_on_main`.
- Changed how features work, this should result in less code that we
need to compile.
- Enums are now real structs instead of type-aliases and free constants.
This is a breaking change, because the system versions of the libraries
used by sctk-adwaita were changed. Such changes cascade through all
the deps, so all libraries using winit MUST do a breaking change.
Tracing is a modern replacement for the log crate that allows for
annotating log messages with the function that they come from.
Signed-off-by: John Nunley <dev@notgull.net>
Closes: #3482
Removes the once_cell dependency, instead using std::sync::OnceLock and a
minimal polyfill for std::sync::LazyLock, which may be stabilized soon
(see rust-lang/rust#121377).
This should not require a bump in MSRV, as OnceLock was stabilized in 1.70,
which this crate is using.
