Update gamepad branch to be consistent with HEAD #1856
Conversation
* Fix issue rust-windowing#1292 * Remove "optionally" from changelog entry
* X11: Sync key press/release with window focus * When a window loses focus, key release events are issued for all pressed keys * When a window gains focus, key press events are issued for all pressed keys * Adds `is_synthetic` field to `WindowEvent` variant `KeyboardInput` to indicate that these events are synthetic. * Adds `is_synthetic: false` to `WindowEvent::KeyboardInput` events issued on all other platforms * Clarify code with comments
* X11: Report `CursorMoved` when touch event occurs * Only trigger CursorMoved events for the first touch ID * Fix testing for current touch events * Fix first touch logic
* Add ModifiersChanged event for macOS This implements the macOS portion of rust-windowing#1124. * Fix ModifiersChanged event import * Fix event passing window instead of device id
…ust-windowing#1322) * On Wayland, fix cursor icon updates on window borders when using CSD * Move changelog entry to a right place
* Fix run_return in MacOS * MacOS: Fix the way of getting a window in run_return * Fix CHANGELOG.md
…tus bar, when starting window in maximized mode (rust-windowing#1324) Mutter can reposition window on resize, if it is behind mutter's "bounding box". So, when you start winit window in maximized mode with CSD, mutter places its CSD behind the GNOME's status bar initially, and then sends configure with the exact same size as your current window. If winit decides to optimize calling frame.resize(..) in this case, we won't call set_geometry(we're calling it through resize) and GNOME won't reposition your window to be inside the "bounding box", which is not a desired behavior for the end user.
…windowing#1323) * FIX rust-windowing#1288 * Fix CHANGELOG.md Co-authored-by: Freya Gentz <[email protected]>
* X11: Fix CursorEntered event for non-winit window * Retry CI Co-authored-by: Osspial <[email protected]>
* Expose set_minimized. Implement for macOS (rust-windowing#985) * Implement set_minimized for Wayland (rust-windowing#985) Co-Authored-By: Victor Berger <[email protected]> * Implement set_minimized for Windows (rust-windowing#985) * Remove debug logs (rust-windowing#985) * Implement Window::set_minimized for X11 * Remove extra param from set_window_flags call * Cargo fmt * Add example of usage * Update changelog * Update feature matrix * Cargo fmt * Update example to remove unnecessary event var * Stop setting window styles when minimizing (rust-windowing#985) * Add stub for WASM (rust-windowing#985) Co-authored-by: Victor Berger <[email protected]> Co-authored-by: Murarth <[email protected]> Co-authored-by: Freya Gentz <[email protected]> Co-authored-by: Osspial <[email protected]>
…ndowing#1330) * Reimplement NativeDisplayMode on iOS for rust-windowing#1310 * Type annotations from code review. Co-Authored-By: Aleksi Juvani <[email protected]> Co-authored-by: Aleksi Juvani <[email protected]>
* Implement changes to `RedrawRequested` event Implements the changes described in rust-windowing#1041 for the X11 platform and for platform-independent public-facing code. * Fix `request_redraw` example * Fix examples in lib docs * Only issue `RedrawRequested` on final `Expose` event
* Move event loop runner to runner module * Implement new redraw API
…ing#1237) Signed-off-by: Heghedus Razvan <[email protected]>
* Implement revamped `RedrawRequested` on Web * Add `web` example
* Implement revamped `RedrawRequested` on iOS * Added RedrawEventsCleared to events_cleared logic * Fixed from comments * Added RedrawEventsCleared to draw_rect handler. * Fixed out of order `RedrawEventsCleared` events. * cargo fmt
Fix window_run_return Make docs build
* Add support for Windows Dark Mode * Add is_dark_mode() getter to WindowExtWindows * Add WindowEvent::DarkModeChanged * Add support for dark mode in Windows 10 builds > 18362 * Change strategy for querying windows 10 build version * Drop window state before sending event Co-Authored-By: daxpedda <[email protected]> * Change implementation of windows dark mode support * Expand supported range of windows 10 versions with dark mode * Use get_function! macro where possible * Minor style fixes * Improve documentation for ThemeChanged * Use `as` conversion for `BOOL` * Correct CHANGELOG entry for dark mode Co-authored-by: daxpedda <[email protected]> Co-authored-by: Osspial <[email protected]>
…st-windowing#1331) * Register windowWillExitFullScreen * On macOS: Do not toggle fullscreen during fullscreen transition * Add CHANGELOG Co-authored-by: Freya Gentz <[email protected]>
…#1307) * X11: Sync key press/release with window focus * When a window loses focus, key release events are issued for all pressed keys * When a window gains focus, key press events are issued for all pressed keys * Adds `is_synthetic` field to `WindowEvent` variant `KeyboardInput` to indicate that these events are synthetic. * Adds `is_synthetic: false` to `WindowEvent::KeyboardInput` events issued on all other platforms * Implement windows focus key press/release on Windows * Docs Co-authored-by: Murarth <[email protected]>
…wing#1826) ndk-glue currently sets both the `ident` field and user-data pointer to `0` or `1` for the event pipe and input queue respectively, to tell these sources apart. While it works to reinterpret this `data` pointer as integer identifier it shouldn't be abused for that, in particular when one may wish to provide extra information with an event in the future; then the `data` field is used as pointer (or abused as abstract value) for that.
The issue was caused by calling SetCapture on a window which already had the capture. The WM_CAPTURECHANGED handler assumed that it would only run if the capture was lost, but that wasn't the case. This made the handler to try to lock the window state mutex while it was already locked. The issue was introduced in rust-windowing#1797 (932cbe4).
…ust-windowing#1847) Following the changes in [1] this bumps ndk and ndk-glue to 0.3 and uses the new constants. The minor version has been bumped to prevent applications from running an older winit (without rust-windowing#1826) with a newer ndk/ndk-glue that does not pass this `ident` through the `data` pointer anymore. [1]: rust-mobile/ndk#112
…dowing#1626) * Link CGDisplayCreateUUIDFromDisplayID through ColorSync instead of CoreGraphics * Conditionally link through ColorSync only if WINIT_LINK_COLORSYNC is set to true * Document new macos env var in README
MarnixKuijs
changed the title
|
Nice job! |
|
@maroider Is there a way to request reviewers? |
|
I can do so, and @msiglreith seems to be aware of this PR, but it is a bit of a monster. There are also merge conflicts for some reason, and I'd like to see those resolved first. |
|
To be perfectly honest here, it feels like there should be a way to merge this that doesn't produce such a daunting PR to review. 179 files with 16,761 lines added and 7,634 lines removed is a bit much. |
|
@maroider I think it could be better to re-make Windows and WASM implementation based on the master. The gamepad implementation does not move for too long and winit has known a bunch of changes. Maybe the implementation needs to be discussed again and have a better monitoring. |
|
@FuriouZz I've been "inspired" to attempt a manual merge of current |
|
So, a quick update on that merging stuff. I've managed to mostly get the Windows backend merged, but I seem to have made a couple of errors while doing so. I'm fairly certain I can salvage it in another attempt by cross-referencing the decisions made in this PR. The web backend, however, is very foreign to me, and it seems like stuff has moved around a lot. Since you're still around and (seemingly) willing to re-do the work on top of |
OK pal! I can re-do the work based on |
|
Well why not override the |
|
Replacing branches like that seems like iffy business to me, sort of like re-writing history on |
|
I could admittedly add a commit reverting the web implementation and then do the merge. |
|
I understand your point. Just curious about the next steps : will we wait the implementation for all backends before merging to |
|
Part of the problem is that no-one maintained the branch, it was just left there to rot. To avoid that, I think we should simply wire up the other backends to the new API surface, and avoid adding anything that isn't already supported on those backends, so we can merge it into |
|
It could be that I messed stuff up. Because I basically remade the implementation of Windows and WASM on top of master. Sorry for the inconvenience. Most of those lines added are just merging master into this branch, also causing the merge conflicts, because both branches are so different. |
|
Sorry for leaving you fine folks hanging for about a month. I'll get something done this week. |
Since the gamepad branch was really old it no longer reflected master. This PR makes it that it does. This should prove helpful for other people who want to contribute to the gamepad branch to, eventually, get its features into master.
See #944 for more detail