Winit version 0.29.2 #3160
Merged
Winit version 0.29.2 #3160
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
* Fix new clippy lints * Fix nightly documentation warnings
This improves CI performance by around 20% (down from 10 to 8 minutes).
* macOS & iOS: Refactor EventWrapper * macOS & iOS: Make EventLoopWindowTarget independent of the user event * iOS: Use MainThreadMarker instead of marking functions unsafe * Make iOS thread safe
Removes Xlib code by replacing it with the x11rb equivalent, the commit handles xrandr, xinput, xinput2, and xkb. Signed-off-by: John Nunley <[email protected]>
* Make Linux platforms less dependent on the root monitor handle * Add various functions to the Wayland platform to reduce cfgs * Don't use a cfg in listen_device_events * Don't use a cfg in set_content_protected * Fix instance of a target_os cfg
They are safe, since they use the rust `std::env` stuff. Making them safe lets downstream to determine that `std::env` is used and not the `libc` env manipulation routines, which are unsafe.
Co-authored-by: nerditation <[email protected]>
Use forced backend over the env variables. Signed-off-by: John Nunley <[email protected]> Fixes: rust-windowing#3057
The new implementation of select_xkb_events apparently misconfigures the server. This commit does a temporary fix by just reverting it to its previous implementation. This is temporary until I can figure out what Xlib is doing behind the scenes or until I read xkbproto.pdf. Fixes: rust-windowing#3079 Signed-off-by: John Nunley <[email protected]>
The dependency is duplicated due to examples, yet we still need to exclude checking it. Fixes rust-windowing#3093.
This should help other crates to integrate winit's event loop into their bigger event loop without adding an extra thread.
Fixing this could require a massive rework to how redraw is handled on windows to the point of removing `WM_PAINT`, since it's not reliable by any means for our use case. For now at least document that the API is broken. It was broken like that for a long while.
Fixes rust-windowing#2905. Co-authored-by: Robert Bragg <[email protected]>
Window builder is always accessed by winit on the thread event loop is on, thus it's safe to mark the data it gets as `Send + Sync`. Each unsafe object is marked individually as `Send + Sync` instead of just implementing `Send` and `Sync` for the whole builder.
Sometimes FlagsChanged events don't carry any KeyCode information, thus we can't create a synthetic presses events for them. However in such cases, modifiers information is still accurate, thus propagate it. Fixes rust-windowing#2872.
|
There was surprisingly little overlap, but done. |
The `rwh_05` feature was not enabled. Fixes: e41fac8 (Update to new raw-window-handle strategy)
It's common to disable Wayland by `WAYLAND_DISPLAY= <application>`.
Split `Key` into clear categories, like `Named`, `Dead`, Character`, `Unidentified` removing the `#[non_exhaustive]` from the `Key` itself. Similar action was done for the `KeyCode`. Fixes: rust-windowing#2995 Co-authored-by: Kirill Chibisov <[email protected]>
The docs are in the src/lib.rs anyway and are present on docs.rs.
The property is marked as `Weak`, however we used strong `Id`. Links: alacritty/alacritty#7249
Co-authored-by: Mads Marquart <[email protected]>
Co-authored-by: Kirill Chibisov <[email protected]>
When calling `Window::request_redraw` from the `RedrawRequested` handler the `RedrawWindow` won't result in `WM_PAINT` being delivered due since user callback is run before `DefWindowProcW` is called. Track whether the user called `Window::request_redraw` and ask for `RedrawWindow` after running the said function during `WM_PAINT` handling. Fixes rust-windowing#3150.
Execute the calls to the IME from the main thread. Fixes rust-windowing#3123.
…wheel device event on Windows While working with device events, I noticed that there was an inconsistency in the mouse button device events between Windows/X11 and for example web, because web uses the same ids/order as the MouseButton enum, and Windows/X11 are using the X11 ids, and hwheel device event was ignored on Windows. Mouse button device events are now using the same order as the MouseButton enum, and I also added hwheel device events for Windows.
The cursor hittest was not reloaded on window size changes, only when `Window::request_inner_size` was called leading to regions of the window being not clickable. Also, don't try to apply hittest logic when user never requested a hittest. Links: alacritty/alacritty#7220
kchibisov
requested review from
jackpot51,
msiglreith,
daxpedda and
madsmtm
as code owners
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.
--
@daxpedda could you squash the web changelog?
CursorEnteredandCursorLeftevents not getting sent when holding a mouse button down #3154