f2de8475fc
* In MacOS, only disable menu bar in exclusive fullscreen * Save and restore fullscreen options in set_fullscreen * Don't always cache presentation options when entering exclusive fullscreen This commit caches presentation options when entering exclusive fullscreen only if we're coming from borderless fullscreen. Then, when transitioning from exclusive -> borderless, if no cached presentation options are present, then the default borderless options are applied. This fixes the menu bar being unavailable when taking the following path: [not fullscreen] -> [exclusive fullscreen] -> [borderless fullscreen]. Without this commit, the presentation options from [not fullscreen] were being cached and then applied to [borderless fullscreen]. * Restore the window level when switching to exclusive fullscreen The hack of using `CGShieldingWindowLevel() + 1` in borderless fullscreen needs to be undone when switching from [borderless] -> [exclusive] fullscreen, otherwise there are menu bar glitches when following a path through [borderless] -> [exclusive] -> [borderless] modes. Now, this might appear to conflict with the 'always on top' feature which uses the 'floating window' level, but this feature appears to be broken anyway when entering and exiting fullscreen with an always-on-top window. So, rather than introducing logic to attempt to restore to the 'floating' level here, I think it's better to do the simple thing for now and then introduce logic for always-on-top windows when fixing the overall fullscreen behaviour. * Update the changelog Co-authored-by: Ehden Sinai <ehdens@gmail.com> Co-authored-by: Francesca Lovebloom <francesca@brainiumstudios.com> |
||
---|---|---|
.github | ||
examples | ||
src | ||
tests | ||
.gitattributes | ||
.gitignore | ||
.gitmodules | ||
build.rs | ||
Cargo.toml | ||
CHANGELOG.md | ||
CONTRIBUTING.md | ||
FEATURES.md | ||
HALL_OF_CHAMPIONS.md | ||
LICENSE | ||
README.md | ||
rustfmt.toml |
winit - Cross-platform window creation and management in Rust
[dependencies]
winit = "0.25.0"
Documentation
For features within the scope of winit, see FEATURES.md.
For features outside the scope of winit, see Missing features provided by other crates in the wiki.
Contact Us
Join us in any of these:
Usage
Winit is a window creation and management library. It can create windows and lets you handle events (for example: the window being resized, a key being pressed, a mouse movement, etc.) produced by window.
Winit is designed to be a low-level brick in a hierarchy of libraries. Consequently, in order to show something on the window you need to use the platform-specific getters provided by winit, or another library.
use winit::{
event::{Event, WindowEvent},
event_loop::{ControlFlow, EventLoop},
window::WindowBuilder,
};
fn main() {
let event_loop = EventLoop::new();
let window = WindowBuilder::new().build(&event_loop).unwrap();
event_loop.run(move |event, _, control_flow| {
*control_flow = ControlFlow::Wait;
match event {
Event::WindowEvent {
event: WindowEvent::CloseRequested,
window_id,
} if window_id == window.id() => *control_flow = ControlFlow::Exit,
_ => (),
}
});
}
Winit is only officially supported on the latest stable version of the Rust compiler.
Cargo Features
Winit provides the following features, which can be enabled in your Cargo.toml
file:
serde
: Enables serialization/deserialization of certain types with Serde.x11
(enabled by default): On Unix platform, compiles with the X11 backendwayland
(enabled by default): On Unix platform, compiles with the Wayland backendmint
: Enables mint (math interoperability standard types) conversions.
Platform-specific usage
WebAssembly
Winit supports compiling to the wasm32-unknown-unknown
target with web-sys
.
On the web platform, a Winit window is backed by a <canvas>
element. You can
either provide Winit with a <canvas>
element, or let Winit
create a <canvas>
element which you can then retrieve and
insert it into the DOM yourself.
For example code using Winit with WebAssembly, check out the web example. For information on using Rust on WebAssembly, check out the Rust and WebAssembly book.
Android
This library makes use of the ndk-rs crates, refer to that repo for more documentation.
The ndk_glue
version needs to match the version used by winit
. Otherwise, the application will not start correctly as ndk_glue
's internal NativeActivity static is not the same due to version mismatch.
ndk_glue
<-> winit
version comparison compatibility:
winit | ndk_glue |
---|---|
0.24 | ndk_glue = "0.2.0" |
0.25 | ndk_glue = "0.3.0" |
0.26 | ndk_glue = "0.4.0" |
Running on an Android device needs a dynamic system library, add this to Cargo.toml:
[[example]]
name = "request_redraw_threaded"
crate-type = ["cdylib"]
And add this to the example file to add the native activity glue:
#[cfg_attr(target_os = "android", ndk_glue::main(backtrace = "on"))]
fn main() {
...
}
And run the application with cargo apk run --example request_redraw_threaded
MacOS
To ensure compatibility with older MacOS systems, winit links to
CGDisplayCreateUUIDFromDisplayID through the CoreGraphics framework.
However, under certain setups this function is only available to be linked
through the newer ColorSync framework. So, winit provides the
WINIT_LINK_COLORSYNC
environment variable which can be set to 1
or true
while compiling to enable linking via ColorSync.