2020-01-05 11:02:41 -05:00
|
|
|
//! Winit is a cross-platform window creation and event loop management library.
|
2014-08-02 20:49:48 +02:00
|
|
|
//!
|
2020-01-05 11:02:41 -05:00
|
|
|
//! # Building windows
|
2014-09-04 11:38:33 +02:00
|
|
|
//!
|
2024-01-31 17:29:59 +04:00
|
|
|
//! Before you can create a [`Window`], you first need to build an [`EventLoop`]. This is done with
|
|
|
|
|
//! the [`EventLoop::new()`] function.
|
2014-09-04 11:38:33 +02:00
|
|
|
//!
|
2017-01-28 15:33:54 +01:00
|
|
|
//! ```no_run
|
2019-02-05 10:30:33 -05:00
|
|
|
//! use winit::event_loop::EventLoop;
|
2023-08-13 23:20:09 +04:00
|
|
|
//! let event_loop = EventLoop::new().unwrap();
|
2017-01-28 15:33:54 +01:00
|
|
|
//! ```
|
|
|
|
|
//!
|
2024-01-31 17:29:59 +04:00
|
|
|
//! Then you create a [`Window`] with [`create_window`].
|
2014-10-04 19:17:02 +02:00
|
|
|
//!
|
2019-02-05 10:30:33 -05:00
|
|
|
//! # Event handling
|
2014-10-04 19:17:02 +02:00
|
|
|
//!
|
2019-06-24 17:30:06 -04:00
|
|
|
//! Once a [`Window`] has been created, it will generate different *events*. A [`Window`] object can
|
2020-01-05 11:02:41 -05:00
|
|
|
//! generate [`WindowEvent`]s when certain input events occur, such as a cursor moving over the
|
|
|
|
|
//! window or a key getting pressed while the window is focused. Devices can generate
|
|
|
|
|
//! [`DeviceEvent`]s, which contain unfiltered event data that isn't specific to a certain window.
|
|
|
|
|
//! Some user activity, like mouse movement, can generate both a [`WindowEvent`] *and* a
|
2023-10-25 17:42:51 +02:00
|
|
|
//! [`DeviceEvent`]. You can also create and handle your own custom [`Event::UserEvent`]s, if desired.
|
2020-01-05 11:02:41 -05:00
|
|
|
//!
|
2024-02-23 14:37:21 +04:00
|
|
|
//! You can retrieve events by calling [`EventLoop::run_app()`]. This function will
|
2020-01-05 11:02:41 -05:00
|
|
|
//! dispatch events for every [`Window`] that was created with that particular [`EventLoop`], and
|
2023-10-25 17:42:51 +02:00
|
|
|
//! will run until [`exit()`] is used, at which point [`Event::LoopExiting`].
|
2017-01-28 15:33:54 +01:00
|
|
|
//!
|
2020-01-05 11:02:41 -05:00
|
|
|
//! Winit no longer uses a `EventLoop::poll_events() -> impl Iterator<Event>`-based event loop
|
2020-11-12 20:49:44 +01:00
|
|
|
//! model, since that can't be implemented properly on some platforms (e.g web, iOS) and works poorly on
|
|
|
|
|
//! most other platforms. However, this model can be re-implemented to an extent with
|
2023-10-25 17:42:51 +02:00
|
|
|
#![cfg_attr(
|
|
|
|
|
any(
|
|
|
|
|
windows_platform,
|
|
|
|
|
macos_platform,
|
|
|
|
|
android_platform,
|
|
|
|
|
x11_platform,
|
|
|
|
|
wayland_platform
|
|
|
|
|
),
|
2024-02-23 14:37:21 +04:00
|
|
|
doc = "[`EventLoopExtPumpEvents::pump_app_events()`][platform::pump_events::EventLoopExtPumpEvents::pump_app_events()]"
|
2023-10-25 17:42:51 +02:00
|
|
|
)]
|
|
|
|
|
#![cfg_attr(
|
|
|
|
|
not(any(
|
|
|
|
|
windows_platform,
|
|
|
|
|
macos_platform,
|
|
|
|
|
android_platform,
|
|
|
|
|
x11_platform,
|
|
|
|
|
wayland_platform
|
|
|
|
|
)),
|
2024-02-23 14:37:21 +04:00
|
|
|
doc = "`EventLoopExtPumpEvents::pump_app_events()`"
|
2023-10-25 17:42:51 +02:00
|
|
|
)]
|
|
|
|
|
//! [^1]. See that method's documentation for more reasons about why
|
2023-12-03 18:39:08 +01:00
|
|
|
//! it's discouraged beyond compatibility reasons.
|
2017-01-28 15:33:54 +01:00
|
|
|
//!
|
|
|
|
|
//!
|
|
|
|
|
//! ```no_run
|
2024-02-23 14:37:21 +04:00
|
|
|
//! use winit::application::ApplicationHandler;
|
|
|
|
|
//! use winit::event::WindowEvent;
|
|
|
|
|
//! use winit::event_loop::{ActiveEventLoop, ControlFlow, EventLoop};
|
|
|
|
|
//! use winit::window::{Window, WindowId};
|
|
|
|
|
//!
|
|
|
|
|
//! #[derive(Default)]
|
|
|
|
|
//! struct App {
|
|
|
|
|
//! window: Option<Window>,
|
|
|
|
|
//! }
|
|
|
|
|
//!
|
|
|
|
|
//! impl ApplicationHandler for App {
|
|
|
|
|
//! fn resumed(&mut self, event_loop: &ActiveEventLoop) {
|
|
|
|
|
//! self.window = Some(event_loop.create_window(Window::default_attributes()).unwrap());
|
|
|
|
|
//! }
|
|
|
|
|
//!
|
|
|
|
|
//! fn window_event(&mut self, event_loop: &ActiveEventLoop, id: WindowId, event: WindowEvent) {
|
|
|
|
|
//! match event {
|
|
|
|
|
//! WindowEvent::CloseRequested => {
|
|
|
|
|
//! println!("The close button was pressed; stopping");
|
|
|
|
|
//! event_loop.exit();
|
|
|
|
|
//! },
|
|
|
|
|
//! WindowEvent::RedrawRequested => {
|
|
|
|
|
//! // Redraw the application.
|
|
|
|
|
//! //
|
|
|
|
|
//! // It's preferable for applications that do not render continuously to render in
|
|
|
|
|
//! // this event rather than in AboutToWait, since rendering in here allows
|
|
|
|
|
//! // the program to gracefully handle redraws requested by the OS.
|
|
|
|
|
//!
|
|
|
|
|
//! // Draw.
|
|
|
|
|
//!
|
|
|
|
|
//! // Queue a RedrawRequested event.
|
|
|
|
|
//! //
|
|
|
|
|
//! // You only need to call this if you've determined that you need to redraw in
|
|
|
|
|
//! // applications which do not always need to. Applications that redraw continuously
|
|
|
|
|
//! // can render here instead.
|
|
|
|
|
//! self.window.as_ref().unwrap().request_redraw();
|
|
|
|
|
//! }
|
|
|
|
|
//! _ => (),
|
|
|
|
|
//! }
|
|
|
|
|
//! }
|
|
|
|
|
//! }
|
2019-06-22 13:26:06 -04:00
|
|
|
//!
|
2023-08-13 23:20:09 +04:00
|
|
|
//! let event_loop = EventLoop::new().unwrap();
|
2017-01-28 15:33:54 +01:00
|
|
|
//!
|
2023-10-10 22:46:08 +02:00
|
|
|
//! // ControlFlow::Poll continuously runs the event loop, even if the OS hasn't
|
|
|
|
|
//! // dispatched any events. This is ideal for games and similar applications.
|
|
|
|
|
//! event_loop.set_control_flow(ControlFlow::Poll);
|
|
|
|
|
//!
|
|
|
|
|
//! // ControlFlow::Wait pauses the event loop if no events are available to process.
|
|
|
|
|
//! // This is ideal for non-game applications that only update in response to user
|
|
|
|
|
//! // input, and uses significantly less power/CPU time than ControlFlow::Poll.
|
|
|
|
|
//! event_loop.set_control_flow(ControlFlow::Wait);
|
|
|
|
|
//!
|
2024-02-23 14:37:21 +04:00
|
|
|
//! let mut app = App::default();
|
|
|
|
|
//! event_loop.run_app(&mut app);
|
2017-01-28 15:33:54 +01:00
|
|
|
//! ```
|
|
|
|
|
//!
|
2023-10-25 17:42:51 +02:00
|
|
|
//! [`WindowEvent`] has a [`WindowId`] member. In multi-window environments, it should be
|
|
|
|
|
//! compared to the value returned by [`Window::id()`] to determine which [`Window`]
|
2020-01-05 11:02:41 -05:00
|
|
|
//! dispatched the event.
|
2014-10-04 19:17:02 +02:00
|
|
|
//!
|
2016-11-03 09:49:19 +01:00
|
|
|
//! # Drawing on the window
|
|
|
|
|
//!
|
2023-12-03 18:39:08 +01:00
|
|
|
//! Winit doesn't directly provide any methods for drawing on a [`Window`]. However, it allows you to
|
2022-07-21 22:22:36 +03:00
|
|
|
//! retrieve the raw handle of the window and display (see the [`platform`] module and/or the
|
|
|
|
|
//! [`raw_window_handle`] and [`raw_display_handle`] methods), which in turn allows
|
2023-10-25 17:42:51 +02:00
|
|
|
//! you to create an OpenGL/Vulkan/DirectX/Metal/etc. context that can be used to render graphics.
|
2019-02-05 10:30:33 -05:00
|
|
|
//!
|
2020-04-20 00:04:30 -04:00
|
|
|
//! Note that many platforms will display garbage data in the window's client area if the
|
|
|
|
|
//! application doesn't render anything to the window by the time the desktop compositor is ready to
|
|
|
|
|
//! display the window to the user. If you notice this happening, you should create the window with
|
2024-01-31 17:29:59 +04:00
|
|
|
//! [`visible` set to `false`](crate::window::WindowAttributes::with_visible) and explicitly make the
|
2020-04-20 00:04:30 -04:00
|
|
|
//! window visible only once you're ready to render into it.
|
|
|
|
|
//!
|
2024-02-26 14:52:00 +01:00
|
|
|
//! # UI scaling
|
|
|
|
|
//!
|
|
|
|
|
//! UI scaling is important, go read the docs for the [`dpi`] crate for an
|
|
|
|
|
//! introduction.
|
|
|
|
|
//!
|
|
|
|
|
//! All of Winit's functions return physical types, but can take either logical or physical
|
|
|
|
|
//! coordinates as input, allowing you to use the most convenient coordinate system for your
|
|
|
|
|
//! particular application.
|
|
|
|
|
//!
|
|
|
|
|
//! Winit will dispatch a [`ScaleFactorChanged`] event whenever a window's scale factor has changed.
|
|
|
|
|
//! This can happen if the user drags their window from a standard-resolution monitor to a high-DPI
|
|
|
|
|
//! monitor or if the user changes their DPI settings. This allows you to rescale your application's
|
|
|
|
|
//! UI elements and adjust how the platform changes the window's size to reflect the new scale
|
|
|
|
|
//! factor. If a window hasn't received a [`ScaleFactorChanged`] event, its scale factor
|
|
|
|
|
//! can be found by calling [`window.scale_factor()`].
|
|
|
|
|
//!
|
|
|
|
|
//! [`ScaleFactorChanged`]: event::WindowEvent::ScaleFactorChanged
|
|
|
|
|
//! [`window.scale_factor()`]: window::Window::scale_factor
|
|
|
|
|
//!
|
2024-02-23 15:35:18 +01:00
|
|
|
//! # Cargo Features
|
|
|
|
|
//!
|
|
|
|
|
//! Winit provides the following Cargo features:
|
|
|
|
|
//!
|
|
|
|
|
//! * `x11` (enabled by default): On Unix platforms, enables the X11 backend.
|
|
|
|
|
//! * `wayland` (enabled by default): On Unix platforms, enables the Wayland
|
|
|
|
|
//! backend.
|
|
|
|
|
//! * `rwh_04`: Implement `raw-window-handle v0.4` traits.
|
|
|
|
|
//! * `rwh_05`: Implement `raw-window-handle v0.5` traits.
|
|
|
|
|
//! * `rwh_06`: Implement `raw-window-handle v0.6` traits.
|
|
|
|
|
//! * `serde`: Enables serialization/deserialization of certain types with
|
|
|
|
|
//! [Serde](https://crates.io/crates/serde).
|
|
|
|
|
//! * `mint`: Enables mint (math interoperability standard types) conversions.
|
|
|
|
|
//!
|
|
|
|
|
//! See the [`platform`] module for documentation on platform-specific cargo
|
|
|
|
|
//! features.
|
|
|
|
|
//!
|
2019-11-11 18:05:59 -05:00
|
|
|
//! [`EventLoop`]: event_loop::EventLoop
|
|
|
|
|
//! [`EventLoop::new()`]: event_loop::EventLoop::new
|
2024-02-23 14:37:21 +04:00
|
|
|
//! [`EventLoop::run_app()`]: event_loop::EventLoop::run_app
|
2024-01-31 17:29:59 +04:00
|
|
|
//! [`exit()`]: event_loop::ActiveEventLoop::exit
|
2019-11-11 18:05:59 -05:00
|
|
|
//! [`Window`]: window::Window
|
2020-01-05 11:02:41 -05:00
|
|
|
//! [`WindowId`]: window::WindowId
|
2024-01-31 17:29:59 +04:00
|
|
|
//! [`WindowAttributes`]: window::WindowAttributes
|
2019-11-11 18:05:59 -05:00
|
|
|
//! [window_new]: window::Window::new
|
2024-01-31 17:29:59 +04:00
|
|
|
//! [`create_window`]: event_loop::ActiveEventLoop::create_window
|
2023-10-25 17:42:51 +02:00
|
|
|
//! [`Window::id()`]: window::Window::id
|
2019-11-11 18:05:59 -05:00
|
|
|
//! [`WindowEvent`]: event::WindowEvent
|
|
|
|
|
//! [`DeviceEvent`]: event::DeviceEvent
|
2023-10-25 17:42:51 +02:00
|
|
|
//! [`Event::UserEvent`]: event::Event::UserEvent
|
|
|
|
|
//! [`Event::LoopExiting`]: event::Event::LoopExiting
|
2020-04-19 11:58:58 -07:00
|
|
|
//! [`raw_window_handle`]: ./window/struct.Window.html#method.raw_window_handle
|
2022-07-21 22:22:36 +03:00
|
|
|
//! [`raw_display_handle`]: ./window/struct.Window.html#method.raw_display_handle
|
2024-02-23 14:37:21 +04:00
|
|
|
//! [^1]: `EventLoopExtPumpEvents::pump_app_events()` is only available on Windows, macOS, Android, X11 and Wayland.
|
2014-08-02 20:49:48 +02:00
|
|
|
|
2019-06-18 02:27:00 +08:00
|
|
|
#![deny(rust_2018_idioms)]
|
2021-08-30 19:40:02 +02:00
|
|
|
#![deny(rustdoc::broken_intra_doc_links)]
|
2022-06-10 13:43:33 +03:00
|
|
|
#![deny(clippy::all)]
|
2023-09-30 21:43:41 +02:00
|
|
|
#![deny(unsafe_op_in_unsafe_fn)]
|
2024-02-28 19:50:05 +02:00
|
|
|
#![cfg_attr(clippy, deny(warnings))]
|
2022-10-24 17:02:52 -05:00
|
|
|
// Doc feature labels can be tested locally by running RUSTDOCFLAGS="--cfg=docsrs" cargo +nightly doc
|
2024-01-04 12:54:35 +01:00
|
|
|
#![cfg_attr(
|
|
|
|
|
docsrs,
|
|
|
|
|
feature(doc_auto_cfg, doc_cfg_hide),
|
|
|
|
|
doc(cfg_hide(doc, docsrs))
|
|
|
|
|
)]
|
2022-06-10 13:43:33 +03:00
|
|
|
#![allow(clippy::missing_safety_doc)]
|
2019-06-18 02:27:00 +08:00
|
|
|
|
2023-10-14 19:07:39 -07:00
|
|
|
#[cfg(feature = "rwh_06")]
|
|
|
|
|
pub use rwh_06 as raw_window_handle;
|
|
|
|
|
|
2024-02-26 14:52:00 +01:00
|
|
|
// Re-export DPI types so that users don't have to put it in Cargo.toml.
|
|
|
|
|
#[doc(inline)]
|
|
|
|
|
pub use dpi;
|
|
|
|
|
|
2024-02-23 14:37:21 +04:00
|
|
|
pub mod application;
|
2019-05-29 21:29:54 -04:00
|
|
|
#[macro_use]
|
|
|
|
|
pub mod error;
|
2023-12-16 22:02:17 +02:00
|
|
|
mod cursor;
|
2019-02-05 10:30:33 -05:00
|
|
|
pub mod event;
|
|
|
|
|
pub mod event_loop;
|
2018-05-07 17:36:21 -04:00
|
|
|
mod icon;
|
2023-05-28 20:02:59 +02:00
|
|
|
pub mod keyboard;
|
2019-06-25 03:15:34 +02:00
|
|
|
pub mod monitor;
|
2019-02-05 10:30:33 -05:00
|
|
|
mod platform_impl;
|
2024-02-25 08:19:27 -08:00
|
|
|
mod utils;
|
2019-02-05 10:30:33 -05:00
|
|
|
pub mod window;
|
2015-09-21 09:15:53 +02:00
|
|
|
|
2019-02-05 10:30:33 -05:00
|
|
|
pub mod platform;
|