Move EventLoopExt* to winit-core (#4228)

* Move EventLoopExtPumpEvents and PumpStatus to winit-core
* Move EventLoopExtRunOnDemand to winit-core

winit-core/src/event_loop/mod.rs

@@ -0,0 +1,291 @@
+pub mod pump_events;
+pub mod run_on_demand;
+
+use std::fmt::{self, Debug};
+use std::sync::atomic::{AtomicUsize, Ordering};
+use std::sync::Arc;
+#[cfg(not(web_platform))]
+use std::time::{Duration, Instant};
+
+use rwh_06::{DisplayHandle, HandleError, HasDisplayHandle};
+#[cfg(web_platform)]
+use web_time::{Duration, Instant};
+
+use crate::as_any::AsAny;
+use crate::cursor::{CustomCursor, CustomCursorSource};
+use crate::error::RequestError;
+use crate::monitor::MonitorHandle;
+use crate::window::{Theme, Window, WindowAttributes};
+
+pub trait ActiveEventLoop: AsAny + fmt::Debug {
+    /// Creates an [`EventLoopProxy`] that can be used to dispatch user events
+    /// to the main event loop, possibly from another thread.
+    fn create_proxy(&self) -> EventLoopProxy;
+
+    /// Create the window.
+    ///
+    /// Possible causes of error include denied permission, incompatible system, and lack of memory.
+    ///
+    /// ## Platform-specific
+    ///
+    /// - **Web:** The window is created but not inserted into the Web page automatically. Please
+    ///   see the Web platform module for more information.
+    fn create_window(
+        &self,
+        window_attributes: WindowAttributes,
+    ) -> Result<Box<dyn Window>, RequestError>;
+
+    /// Create custom cursor.
+    ///
+    /// ## Platform-specific
+    ///
+    /// **iOS / Android / Orbital:** Unsupported.
+    fn create_custom_cursor(
+        &self,
+        custom_cursor: CustomCursorSource,
+    ) -> Result<CustomCursor, RequestError>;
+
+    /// Returns the list of all the monitors available on the system.
+    ///
+    /// ## Platform-specific
+    ///
+    /// **Web:** Only returns the current monitor without `detailed monitor permissions`.
+    fn available_monitors(&self) -> Box<dyn Iterator<Item = MonitorHandle>>;
+
+    /// Returns the primary monitor of the system.
+    ///
+    /// Returns `None` if it can't identify any monitor as a primary one.
+    ///
+    /// ## Platform-specific
+    ///
+    /// - **Wayland:** Always returns `None`.
+    /// - **Web:** Always returns `None` without `detailed monitor permissions`.
+    fn primary_monitor(&self) -> Option<MonitorHandle>;
+
+    /// Change if or when [`DeviceEvent`]s are captured.
+    ///
+    /// Since the [`DeviceEvent`] capture can lead to high CPU usage for unfocused windows, winit
+    /// will ignore them by default for unfocused windows on Linux/BSD. This method allows changing
+    /// this at runtime to explicitly capture them again.
+    ///
+    /// ## Platform-specific
+    ///
+    /// - **Wayland / macOS / iOS / Android / Orbital:** Unsupported.
+    ///
+    /// [`DeviceEvent`]: crate::event::DeviceEvent
+    fn listen_device_events(&self, allowed: DeviceEvents);
+
+    /// Returns the current system theme.
+    ///
+    /// Returns `None` if it cannot be determined on the current platform.
+    ///
+    /// ## Platform-specific
+    ///
+    /// - **iOS / Android / Wayland / x11 / Orbital:** Unsupported.
+    fn system_theme(&self) -> Option<Theme>;
+
+    /// Sets the [`ControlFlow`].
+    fn set_control_flow(&self, control_flow: ControlFlow);
+
+    /// Gets the current [`ControlFlow`].
+    fn control_flow(&self) -> ControlFlow;
+
+    /// Stop the event loop.
+    ///
+    /// ## Platform-specific
+    ///
+    /// ### iOS
+    ///
+    /// It is not possible to programmatically exit/quit an application on iOS, so this function is
+    /// a no-op there. See also [this technical Q&A][qa1561].
+    ///
+    /// [qa1561]: https://developer.apple.com/library/archive/qa/qa1561/_index.html
+    fn exit(&self);
+
+    /// Returns whether the [`ActiveEventLoop`] is about to stop.
+    ///
+    /// Set by [`exit()`][Self::exit].
+    fn exiting(&self) -> bool;
+
+    /// Gets a persistent reference to the underlying platform display.
+    ///
+    /// See the [`OwnedDisplayHandle`] type for more information.
+    fn owned_display_handle(&self) -> OwnedDisplayHandle;
+
+    /// Get the raw-window-handle handle.
+    fn rwh_06_handle(&self) -> &dyn HasDisplayHandle;
+}
+
+impl HasDisplayHandle for dyn ActiveEventLoop + '_ {
+    fn display_handle(&self) -> Result<DisplayHandle<'_>, HandleError> {
+        self.rwh_06_handle().display_handle()
+    }
+}
+
+impl_dyn_casting!(ActiveEventLoop);
+
+/// Control the [`ActiveEventLoop`], possibly from a different thread, without referencing it
+/// directly.
+#[derive(Clone, Debug)]
+pub struct EventLoopProxy {
+    pub(crate) proxy: Arc<dyn EventLoopProxyProvider>,
+}
+
+impl EventLoopProxy {
+    /// Wake up the [`ActiveEventLoop`], resulting in [`ApplicationHandler::proxy_wake_up()`] being
+    /// called.
+    ///
+    /// Calls to this method are coalesced into a single call to [`proxy_wake_up`], see the
+    /// documentation on that for details.
+    ///
+    /// If the event loop is no longer running, this is a no-op.
+    ///
+    /// [`proxy_wake_up`]: crate::application::ApplicationHandler::proxy_wake_up
+    /// [`ApplicationHandler::proxy_wake_up()`]: crate::application::ApplicationHandler::proxy_wake_up
+    ///
+    /// # Platform-specific
+    ///
+    /// - **Windows**: The wake-up may be ignored under high contention, see [#3687].
+    ///
+    /// [#3687]: https://github.com/rust-windowing/winit/pull/3687
+    pub fn wake_up(&self) {
+        self.proxy.wake_up();
+    }
+
+    pub fn new(proxy: Arc<dyn EventLoopProxyProvider>) -> Self {
+        Self { proxy }
+    }
+}
+
+pub trait EventLoopProxyProvider: Send + Sync + Debug {
+    /// See [`EventLoopProxy::wake_up`] for details.
+    fn wake_up(&self);
+}
+
+/// A proxy for the underlying display handle.
+///
+/// The purpose of this type is to provide a cheaply cloneable handle to the underlying
+/// display handle. This is often used by graphics APIs to connect to the underlying APIs.
+/// It is difficult to keep a handle to the underlying event loop type or the [`ActiveEventLoop`]
+/// type. In contrast, this type involves no lifetimes and can be persisted for as long as
+/// needed.
+///
+/// For all platforms, this is one of the following:
+///
+/// - A zero-sized type that is likely optimized out.
+/// - A reference-counted pointer to the underlying type.
+#[derive(Clone)]
+pub struct OwnedDisplayHandle {
+    pub(crate) handle: Arc<dyn HasDisplayHandle>,
+}
+
+impl OwnedDisplayHandle {
+    pub fn new(handle: Arc<dyn HasDisplayHandle>) -> Self {
+        Self { handle }
+    }
+}
+
+impl HasDisplayHandle for OwnedDisplayHandle {
+    fn display_handle(&self) -> Result<DisplayHandle<'_>, HandleError> {
+        self.handle.display_handle()
+    }
+}
+
+impl fmt::Debug for OwnedDisplayHandle {
+    fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
+        f.debug_struct("OwnedDisplayHandle").finish_non_exhaustive()
+    }
+}
+
+impl PartialEq for OwnedDisplayHandle {
+    fn eq(&self, other: &Self) -> bool {
+        match (self.display_handle(), other.display_handle()) {
+            (Ok(lhs), Ok(rhs)) => lhs == rhs,
+            _ => false,
+        }
+    }
+}
+
+impl Eq for OwnedDisplayHandle {}
+
+/// Set through [`ActiveEventLoop::set_control_flow()`].
+///
+/// Indicates the desired behavior of the event loop after [`about_to_wait`] is called.
+///
+/// Defaults to [`Wait`].
+///
+/// [`Wait`]: Self::Wait
+/// [`about_to_wait`]: crate::application::ApplicationHandler::about_to_wait
+#[derive(Copy, Clone, Debug, Default, PartialEq, Eq, Hash)]
+pub enum ControlFlow {
+    /// When the current loop iteration finishes, immediately begin a new iteration regardless of
+    /// whether or not new events are available to process.
+    Poll,
+
+    /// When the current loop iteration finishes, suspend the thread until another event arrives.
+    #[default]
+    Wait,
+
+    /// When the current loop iteration finishes, suspend the thread until either another event
+    /// arrives or the given time is reached.
+    ///
+    /// Useful for implementing efficient timers. Applications which want to render at the
+    /// display's native refresh rate should instead use [`Poll`] and the VSync functionality
+    /// of a graphics API to reduce odds of missed frames.
+    ///
+    /// [`Poll`]: Self::Poll
+    WaitUntil(Instant),
+}
+
+impl ControlFlow {
+    /// Creates a [`ControlFlow`] that waits until a timeout has expired.
+    ///
+    /// In most cases, this is set to [`WaitUntil`]. However, if the timeout overflows, it is
+    /// instead set to [`Wait`].
+    ///
+    /// [`WaitUntil`]: Self::WaitUntil
+    /// [`Wait`]: Self::Wait
+    pub fn wait_duration(timeout: Duration) -> Self {
+        match Instant::now().checked_add(timeout) {
+            Some(instant) => Self::WaitUntil(instant),
+            None => Self::Wait,
+        }
+    }
+}
+
+/// Control when device events are captured.
+#[derive(Copy, Clone, PartialEq, Eq, PartialOrd, Ord, Hash, Debug, Default)]
+#[cfg_attr(feature = "serde", derive(serde::Serialize, serde::Deserialize))]
+pub enum DeviceEvents {
+    /// Report device events regardless of window focus.
+    Always,
+    /// Only capture device events while the window is focused.
+    #[default]
+    WhenFocused,
+    /// Never capture device events.
+    Never,
+}
+
+/// A unique identifier of the winit's async request.
+///
+/// This could be used to identify the async request once it's done
+/// and a specific action must be taken.
+///
+/// One of the handling scenarios could be to maintain a working list
+/// containing [`AsyncRequestSerial`] and some closure associated with it.
+/// Then once event is arriving the working list is being traversed and a job
+/// executed and removed from the list.
+#[derive(Debug, Clone, Copy, PartialEq, Eq, Hash)]
+pub struct AsyncRequestSerial {
+    serial: usize,
+}
+
+impl AsyncRequestSerial {
+    pub fn get() -> Self {
+        static CURRENT_SERIAL: AtomicUsize = AtomicUsize::new(0);
+        // NOTE: We rely on wrap around here, while the user may just request
+        // in the loop usize::MAX times that's issue is considered on them.
+        let serial = CURRENT_SERIAL.fetch_add(1, Ordering::Relaxed);
+        Self { serial }
+    }
+}

winit-core/src/event_loop/pump_events.rs

@@ -0,0 +1,116 @@
+use std::time::Duration;
+
+use crate::application::ApplicationHandler;
+
+#[allow(rustdoc::broken_intra_doc_links)] // FIXME(madsmtm): Fix these.
+/// Additional methods on [`EventLoop`] for pumping events within an external event loop
+pub trait EventLoopExtPumpEvents {
+    /// Pump the `EventLoop` to check for and dispatch pending events.
+    ///
+    /// This API is designed to enable applications to integrate Winit into an
+    /// external event loop, for platforms that can support this.
+    ///
+    /// The given `timeout` limits how long it may block waiting for new events.
+    ///
+    /// Passing a `timeout` of `Some(Duration::ZERO)` would ensure your external
+    /// event loop is never blocked but you would likely need to consider how
+    /// to throttle your own external loop.
+    ///
+    /// Passing a `timeout` of `None` means that it may wait indefinitely for new
+    /// events before returning control back to the external loop.
+    ///
+    /// **Note:** This is not a portable API, and its usage involves a number of
+    /// caveats and trade offs that should be considered before using this API!
+    ///
+    /// You almost certainly shouldn't use this API, unless you absolutely know it's
+    /// the only practical option you have.
+    ///
+    /// ## Synchronous events
+    ///
+    /// Some events _must_ only be handled synchronously via the closure that
+    /// is passed to Winit so that the handler will also be synchronized with
+    /// the window system and operating system.
+    ///
+    /// This is because some events are driven by a window system callback
+    /// where the window systems expects the application to have handled the
+    /// event before returning.
+    ///
+    /// **These events can not be buffered and handled outside of the closure
+    /// passed to Winit.**
+    ///
+    /// As a general rule it is not recommended to ever buffer events to handle
+    /// them outside of the closure passed to Winit since it's difficult to
+    /// provide guarantees about which events are safe to buffer across all
+    /// operating systems.
+    ///
+    /// Notable events that will certainly create portability problems if
+    /// buffered and handled outside of Winit include:
+    /// - `RedrawRequested` events, used to schedule rendering.
+    ///
+    ///   macOS for example uses a `drawRect` callback to drive rendering
+    ///   within applications and expects rendering to be finished before
+    ///   the `drawRect` callback returns.
+    ///
+    ///   For portability it's strongly recommended that applications should
+    ///   keep their rendering inside the closure provided to Winit.
+    /// - Any lifecycle events, such as `Suspended` / `Resumed`.
+    ///
+    ///   The handling of these events needs to be synchronized with the
+    ///   operating system and it would never be appropriate to buffer a
+    ///   notification that your application has been suspended or resumed and
+    ///   then handled that later since there would always be a chance that
+    ///   other lifecycle events occur while the event is buffered.
+    ///
+    /// ## Supported Platforms
+    ///
+    /// - Windows
+    /// - Linux
+    /// - MacOS
+    /// - Android
+    ///
+    /// ## Unsupported Platforms
+    ///
+    /// - **Web:**  This API is fundamentally incompatible with the event-based way in which Web
+    ///   browsers work because it's not possible to have a long-running external loop that would
+    ///   block the browser and there is nothing that can be polled to ask for new new events.
+    ///   Events are delivered via callbacks based on an event loop that is internal to the browser
+    ///   itself.
+    /// - **iOS:** It's not possible to stop and start an `NSApplication` repeatedly on iOS so
+    ///   there's no way to support the same approach to polling as on MacOS.
+    ///
+    /// ## Platform-specific
+    ///
+    /// - **Windows**: The implementation will use `PeekMessage` when checking for window messages
+    ///   to avoid blocking your external event loop.
+    ///
+    /// - **MacOS**: The implementation works in terms of stopping the global application whenever
+    ///   the application `RunLoop` indicates that it is preparing to block and wait for new events.
+    ///
+    ///   This is very different to the polling APIs that are available on other
+    ///   platforms (the lower level polling primitives on MacOS are private
+    ///   implementation details for `NSApplication` which aren't accessible to
+    ///   application developers)
+    ///
+    ///   It's likely this will be less efficient than polling on other OSs and
+    ///   it also means the `NSApplication` is stopped while outside of the Winit
+    ///   event loop - and that's observable (for example to crates like `rfd`)
+    ///   because the `NSApplication` is global state.
+    ///
+    ///   If you render outside of Winit you are likely to see window resizing artifacts
+    ///   since MacOS expects applications to render synchronously during any `drawRect`
+    ///   callback.
+    fn pump_app_events<A: ApplicationHandler>(
+        &mut self,
+        timeout: Option<Duration>,
+        app: A,
+    ) -> PumpStatus;
+}
+
+/// The return status for `pump_events`
+#[derive(Clone, Copy, Debug, Eq, Hash, PartialEq)]
+pub enum PumpStatus {
+    /// Continue running external loop.
+    Continue,
+    /// Exit external loop.
+    Exit(i32),
+}

winit-core/src/event_loop/run_on_demand.rs

@@ -0,0 +1,65 @@
+use crate::application::ApplicationHandler;
+use crate::error::EventLoopError;
+#[cfg(doc)]
+use crate::{
+    event_loop::{pump_events::EventLoopExtPumpEvents, ActiveEventLoop},
+    window::Window,
+};
+
+#[allow(rustdoc::broken_intra_doc_links)] // FIXME(madsmtm): Fix these.
+/// Additional methods on [`EventLoop`] to return control flow to the caller.
+pub trait EventLoopExtRunOnDemand {
+    /// Run the application with the event loop on the calling thread.
+    ///
+    /// Unlike [`EventLoop::run_app`], this function accepts non-`'static` (i.e. non-`move`)
+    /// closures and it is possible to return control back to the caller without
+    /// consuming the `EventLoop` (by using [`exit()`]) and
+    /// so the event loop can be re-run after it has exit.
+    ///
+    /// It's expected that each run of the loop will be for orthogonal instantiations of your
+    /// Winit application, but internally each instantiation may re-use some common window
+    /// system resources, such as a display server connection.
+    ///
+    /// This API is not designed to run an event loop in bursts that you can exit from and return
+    /// to while maintaining the full state of your application. (If you need something like this
+    /// you can look at the [`EventLoopExtPumpEvents::pump_app_events()`] API)
+    ///
+    /// Each time `run_app_on_demand` is called the startup sequence of `init`, followed by
+    /// `resume` is being preserved.
+    ///
+    /// See the [`set_control_flow()`] docs on how to change the event loop's behavior.
+    ///
+    /// # Caveats
+    /// - This extension isn't available on all platforms, since it's not always possible to return
+    ///   to the caller (specifically this is impossible on iOS and Web - though with the Web
+    ///   backend it is possible to use
+    #[cfg_attr(
+        web_platform,
+        doc = "  [`EventLoopExtWeb::spawn_app()`][crate::platform::web::EventLoopExtWeb::spawn_app()]"
+    )]
+    #[cfg_attr(not(web_platform), doc = "  `EventLoopExtWeb::spawn_app()`")]
+    ///   [^1] more than once instead).
+    /// - No [`Window`] state can be carried between separate runs of the event loop.
+    ///
+    /// You are strongly encouraged to use [`EventLoop::run_app()`] for portability, unless you
+    /// specifically need the ability to re-run a single event loop more than once
+    ///
+    /// # Supported Platforms
+    /// - Windows
+    /// - Linux
+    /// - macOS
+    /// - Android
+    ///
+    /// # Unsupported Platforms
+    /// - **Web:**  This API is fundamentally incompatible with the event-based way in which Web
+    ///   browsers work because it's not possible to have a long-running external loop that would
+    ///   block the browser and there is nothing that can be polled to ask for new events. Events
+    ///   are delivered via callbacks based on an event loop that is internal to the browser itself.
+    /// - **iOS:** It's not possible to stop and start an `UIApplication` repeatedly on iOS.
+    ///
+    /// [^1]: `spawn_app()` is only available on the Web platforms.
+    ///
+    /// [`exit()`]: ActiveEventLoop::exit()
+    /// [`set_control_flow()`]: ActiveEventLoop::set_control_flow()
+    fn run_app_on_demand<A: ApplicationHandler>(&mut self, app: A) -> Result<(), EventLoopError>;
+}