Update to v0.30.8 #15
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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: 94664ff (Don't set the background color)
This is a breaking change, thus revert it for patch series.
The c_char type, which was used under the hood is different depending on arch, thus use it directly instead of i8. Fixes rust-windowing#3735.
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.
The latter syntax is deprecated and will be removed in Rust 2024 edition. This also generates a warning with current versions of Rust.
taiki-e/checkout-action has a few advantages over actions/checkout, such as: - It is written in Bash rather than Node.js - It does not have frequent breaking changes, reducing churn Signed-off-by: John Nunley <[email protected]>
Rust tooling generally works better this way. This includes rust-analyzer, but more noticeably the output from `tracing` typically prints the module path, which did not correspond to the actual file system before. Concretely, tracing output from the macOS backend changes from printing: `winit::platform_impl::platform::util` To printing: `winit::platform_impl::macos::util`
Nothing wrong will happen if we ignore events when compositor is at wrong, at least crashing because compositor is just _wrong_ probably is not a great option. Links: alacritty/alacritty#8065
Update SCTK as a follow-up to 1170554 (ignore events to dead objects) fixing it for wl_output.
`clippy::doc_lazy_continuation` was added, which needed some fixing from our side.
This type comes from the user and stored for the entire lifetime, so no need to hide it from them after they've passed it to winit. Fixes rust-windowing#3818.
This was detected by a new change in Nightly Rust that applied `#[must_use]` to the return value of `Box::into_raw()`.
Co-authored-by: Mads Marquart <[email protected]>
Return error from it instead of unwrapping.
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 rust-windowing#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]: rust-windowing#3950 (comment)
Based on rust-windowing#3973, which should be merged first. There's an API to programmatically specify X11 screen id (override what is determined from the `DISPLAY` env variable), but it doesn't work. Seeting up X Server with 2 screens and calling `DISPLAY=:0 X11_SCREEN_ID=1 cargo run --example window` should be equivalent to calling `DISPLAY=:0.1 cargo run --example window` The latter works (and places the window on the correct screen), but the former yields `failed to create initial window: Os(OsError { line: 620, file: "src/platform_impl/linux/x11/window.rs", error: X11Error(X11Error { error_kind: Match, error_code: 8, sequence: 219, bad_value: 1319, minor_opcode: 0, major_opcode: 1, extension_name: None, request_name: Some("CreateWindow") }) })` _Here `1319` is the root window id for screen 0, which doesn't match the screen 1 that we request._ The problem is that we need to factor in the screen id when determining the parent (root) window when not explicitly set. This patch does that. --- Also: Extend the window example with X11_{SCREEN,VISUAL}_ID env variables
This is not strictly required, but makes the examples a bit easier to read understand (especially since the `EventLoop` really _should_ be created inside `fn main`, and not in some random function potentially running on a random thread).
Route it via the `Window::set_ime_allowed` like on iOS.
This implements basic iOS IME support (typing, backspace, support for emojis etc but no autocomplete or copy / paste menu). Co-authored-by: Mads Marquart <[email protected]>
It should be done before mapping the window, or we could lose the firsst XInput2 events, such as the first FocusIn. Fixes rust-windowing#2841.
Events emitted by `flagsChanged:` cannot access `charactersIgnoringModifiers`. We were previously doing this because we were trying to re-use the `create_key_event` function, but that is unsuited for this purpose, so I have separated the `flagsChanged:` logic out from it.
`AnyClass::responds_to` delegates to `class_respondsToSelector`, a function provided by the Objective-C runtime. However, at some point, this began to return `false` for selectors referring to undocumented cursors, despite the cursors remaining accessible via said selectors. That this check fails prevents the cursors from being used. We can instead send `respondsToSelector:` to the `NSCursor` class itself. As an instance method, this is nominally impossible; however, Apple grants an exemption[1] that permits class objects to perform instance methods defined in the root class. Checking for the undocumented cursors in this way gets them working again, at least on macOS Sequoia 15.1.1. [1]: https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/ObjectiveC/Chapters/ocObjectsClasses.html#//apple_ref/doc/uid/TP30001163-CH11-TPXREF120
Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: daxpedda <[email protected]>
The filtered events were still processed even though they shouldn't once we know that they're filtered. Fixes rust-windowing#4048.
GNOME doesn't list that there's a _NONE_ style at all, but it still works if you use it.
This is needed when passing and getting token from the IPC to activate the window.
Winit version 0.30.8
4 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR updates this fork from winit v0.30.1 to v0.30.8. This brings several bug fixes including the fix for iced-rs/iced#2727.
https://docs.rs/winit/latest/winit/changelog/index.html
This PR just merges the upstream's v0.30.8 tag into the v0.30.x branch. The conflict was very small so I manually fixed it and checked some examples in iced-rs/iced:
Fixes iced-rs/iced#2727