Update winit dependency to 0.29 #8745

Vrixyz · 2023-06-02T16:02:50Z

⚠️ ⚠️ ⚠️ ⚠️ ⚠️ ⚠️ ⚠️ ⚠️ ⚠️
⚠️ Closed in favor of #10702 ⚠️
⚠️ ⚠️ ⚠️ ⚠️ ⚠️ ⚠️ ⚠️ ⚠️ ⚠️

#10702 only builds on this PR but without obsolete comments and discussions.

Objective

Update winit dependency to 0.29

Changelog

Changed most KeyCode values, they now represent physical keys (and could infer their scancode) rather than logical
- Behind other PR: new KeyLogic::Logic(Key), with "regular" characters behind a SmolStr.
Use web-time rather than instant crate. (Replace instant with web-time rust-windowing/winit#2836)
winit did split run_return in run_onDemand and pump_events, I did the same change in bevy_winit and used pump_events.
Removed return_from_run from WinitSettings as winit::run now returns on supported platforms.
- I left the example "return_after_run" as I think it's still useful.
- This winit change is done partly to allow to create a new window after quitting all windows: eframe: create multiple windows in sequence emilk/egui#1918 ; this PR doesn't address.

Call for help

❓ I'd like more feedbacks on winit 0.29: Ergonomics, examples + keymap cache Vrixyz/bevy#3
❓ I noticed a licence file in the winit file from which we're copying most our data types: https://github.com/rust-windowing/winit/blob/master/src/keyboard.rs ; should we do something about it ?

Answered interrogations

API complexity

I'm not sure about this new API, it seems cumbersome to do #8745 (comment)

- keycode.is_pressed(KeyCode::KeyQ)
+ key.is_pressed(Key::Character("q".into()))

✅ Leverage Into to support key.is_pressed("q")

Copy incompatible with SmolStr

We should add a logical Key based on winit's Key, but bevy's KeyboardInput is Copy, but SmolStr is not, so I'm not sure how to proceed ?

remove Copy ? I feel like it's a bad idea because events are usually Copy.
- ✅ remove copy when problematic
use Cow or something..?
- ✅ use SmolStr with added reflection
~~add Copy upstream to SmolStr (I think that won't pass, if at all possible)~~
~~use another type ? plain String...~~
~~use our curated list of supported characters/string as enum, but that doesn't sound great (because chinese characters, copy/paste/IME probably wouldn't be supported this way.~~
✅ stick to copying winit's types as much as possible

Blockers

Because this PR is big already, I separated:
- winit 0.29: Ergonomics, examples + keymap cache Vrixyz/bevy#3
winit 0.29
accesskit_winit: to update to winit 0.29 ; ok

Follow up

I'd like to avoid bloating this PR, here are a few follow up tasks worthy of a separate PR, or new issue to track them one this PR is closed:

NamedKey integration on bevy_input: Revise Key, KeyCode enums rust-windowing/winit#3143 introduced a new NamedKey variant. I implemented it only on the converters but we'd benefit making the same changes to bevy_input (that means also more changes to examples, etc.).
macOS Sonoma (14.0) / Xcode 15.0 — Compatibility Fixes + Docs #9905 added a workaround on a bug fixed by winit 0.29.
on Android, Raw window handle strategy rust-mobile/android-activity#141 is pulling an unneeded dependency if we're keeping raw-window-handle 0.5 (we don't want to update to 0.6 until wgpu does, I guess we don't want to follow the maintainance burden of supporting multiple raw window handle versions).
Allow receiving multiple characters through ReceivedCharacter: This PR only sends the first character, comment
remove instant dependency, replaced by web_time)
- fastrand 2.0 did the switch, but following dependencies did not update to fastrand 2.0:
  - async-executor
  - futures-lite

Migration Guide

This PR should have one.

alice-i-cecile · 2023-06-02T16:06:58Z

We should add a logical Key based on winit's Key, but bevy's KeyboardInput is Copy, but SmolStr is not, so I'm not sure how to proceed ?

IMO we should probably just remove the Copy bound here. Exposing this information is important, and all the other workarounds are worse than just having to call .clone().

daxpedda · 2023-06-03T11:30:25Z

The Web backend in Winit had quite a bit of churn lately, let me know if you uncover any bugs or issues.

Vrixyz · 2023-06-03T21:03:23Z

with 54483f9, I'm exploring:

For logical key, I make bevy_input declare a Key<String> populated from winit's Key<SmolStr>, it's easier to implement for me so I don't get FromReflect errors because of SmolStr.
In KeyboardInput, ^ That logical key is now a field logical_key: Key, and replaces key_code: ScanCode
The type ScanCode is replaced by a KeyCode, and rename KeyboardInput's scan_code to key_code
- ⚠️ I think it's wrong because for bevy user's perspective it means key_code switches from being the logical key to the physical key, and could be missed. That makes our wording more consistent with winit's though.

Vrixyz · 2023-06-03T21:03:45Z

IMO we should probably just remove the Copy bound here. Exposing this information is important, and all the other workarounds are worse than just having to call .clone().

Unfortunately this option proves to be difficult, bevy's input system involves app.init_resource::<Input<Key>>(), where Input<T:Copy>, I'm not sure how to proceed. (we can remove Copy from Input, would that be accepted?)

alice-i-cecile · 2023-06-03T23:00:35Z

Removing the Copy bound from Input is totally fine: I don't think there's a strong reason to require that.

…nput

examples/input/keyboard_input.rs

Prompted by winit's update bevyengine#8745.

# Objective To upgrade winit's dependency, it's useful to reuse SmolStr, which replaces/improves the too restrictive Key letter enums. As Input<Key> is a resource it should implement Reflect through all its fields. ## Solution Add smol_str to bevy_reflect supported types, behind a feature flag. This PR blocks winit's upgrade PR: #8745. # Current state - I'm discovering bevy_reflect, I appreciate all feedbacks, and send me your nitpicks! - Lacking more tests --------- Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com> Co-authored-by: Gino Valente <49806985+MrGVSV@users.noreply.github.com>

Vrixyz · 2023-06-08T21:23:37Z

@alice-i-cecile I think this PR can be removed from 0.11 milestone, because winit doesn't plan to release 0.29 until august.

github-actions · 2023-06-09T07:37:19Z

Example alien_cake_addict failed to run, please try running it locally and check the result.

github-actions · 2023-06-09T07:42:36Z

Example alien_cake_addict failed to run, please try running it locally and check the result.

github-actions · 2023-06-09T09:03:08Z

Example alien_cake_addict failed to run, please try running it locally and check the result.

github-actions · 2023-06-09T09:48:34Z

Example alien_cake_addict failed to run, please try running it locally and check the result.

alice-i-cecile · 2023-10-22T23:25:55Z

No longer blocked following the winit 0.29 release 🎉

simbleau · 2023-10-25T03:24:46Z

🙏

@Vrixyz for those who may stuble upon this, how is this issue/pr related to fixing the bevy_egui issue where non-qwerty keyboards can't type symbols or special characters on wasm32?

few format tweaks, initially spotted working on #8745

Vrixyz · 2023-10-27T20:07:31Z

🙏

@Vrixyz for those who may stuble upon this, how is this issue/pr related to fixing the bevy_egui issue where non-qwerty keyboards can't type symbols or special characters on wasm32?

To answer "in short": I tracked it to the example char_input_events on bevy wasm, and noticed such special characters were not printed. winit refactored the keyboard input and I believe that's a good step towards fixing that issue.

For a longer context: vladbat00/bevy_egui#178 (comment) -> this doesn't explicitly mentions special characters but it's a bit all related (other recap of the context here: https://thierryberger.com/drafts/contribution-story-winit/)

few format tweaks, initially spotted working on bevyengine#8745

Vrixyz · 2023-11-08T16:06:12Z

No longer blocked following the winit 0.29 release 🎉

For exactness, we were still blocked by accesskit, but it's not longer the case following https://github.com/AccessKit/accesskit/releases/tag/accesskit_winit-v0.16.0 🎉

tim-blackbird · 2023-11-08T18:42:18Z

futures-lite has also updated to fastrand 2.0 since

tim-blackbird

Reviewed! This is a great step forward for input handling c:

tim-blackbird · 2023-11-08T18:00:18Z

crates/bevy_winit/src/lib.rs

+                            converters::convert_keyboard_input(event, window_entity);
+                        if let bevy_input::keyboard::Key::Character(c) = &keyboard_event.logical_key
+                        {
+                            if let Some(first_char) = c.chars().next() {


Is sending only the first character correct here?

I.. guess not, but sending the whole SmolStr within ReceivedCharacter seemed a big change when I was on it.

I can see multiple solutions:

sending SmolStr.

sending several ReceivedCharacter(char)

splitting ReceivedCharacter and ReceivedMultipleCharacters ?

I thought this implementation was the closest to current main behaviour, so that might be OK as a first approach.
I'm writing that in "Follow Up" for the time being.

tim-blackbird · 2023-11-08T18:04:27Z

crates/bevy_winit/src/lib.rs

+                            if inner_size_writer.request_inner_size(new_inner_size).is_ok() {
+                                new_inner_size = maybe_new_inner_size;
+                            }


Perhaps it makes sense to log the failure case here.

crates/bevy_winit/src/lib.rs

tim-blackbird · 2023-11-08T18:17:03Z

crates/bevy_winit/src/lib.rs

-    } else {
-        run(event_loop, event_handler);
-    }
+    let _ = run(event_loop, event_handler);


We should log the error here.

tim-blackbird · 2023-11-08T18:21:55Z

crates/bevy_winit/src/system.rs

@@ -174,7 +174,7 @@ pub(crate) fn changed_windows(
                    window.resolution.physical_width(),
                    window.resolution.physical_height(),
                );
-                winit_window.set_inner_size(physical_size);
+                let _ = winit_window.request_inner_size(physical_size);


Looks like we should handle this returning Some. From the docs:

On platforms where the size is entirely controlled by the user the applied size will be returned immediately, resize event in such case may not be generated.

(link to docs)
" may not be generated " 🙁 ; I don't like uncertainty...

this seems to only affect wayland? ; but the exact path to the maybe not generated event is quite hard to follow 🤔...

I'll follow the trail to winit and might open an issue because I'd like to handle differently:

Some(newValue): generate an event resize like we do when reacting from events ⚠️ the "may" from the docs may cause the event to be sent twice.

Some(oldValue): do not generate an event resize ⚠️ I cannot differentiate it from a new value, so I'd send "useless" resize. Well I guess we're not supposed to send a resize event in those platforms anyway but still.

None: event will be sent afterward, or not ✅

maybe the docs is wrong and should read "will not be generated", so I can handle it with certainty 🤞.

Thanks for bringing up resizing, my PR has a regression, as window is not redrawn during resizing.

My PR

(rev aaa3368)

resizing_PR_8745.mp4

On main

(rev 0cc1179)

resizing_main_0cc11791b9a55f5d310ee754c9f7254081e7138a.mp4

tim-blackbird · 2023-11-08T18:31:23Z

crates/bevy_winit/src/winit_windows.rs

@@ -194,7 +194,7 @@ impl WinitWindows {
            use winit::platform::web::WindowExtWebSys;

            if window.canvas.is_none() {
-                let canvas = winit_window.canvas();
+                let canvas = winit_window.canvas().unwrap();


The docs for this state

Only returns the canvas if called from inside the window.

I'm not sure what that means.

I think it's alright to call unwrap on that, I believe it's instantiated at the same time of a window, so it might fail if you're doing convoluted things like modifying the canvas from javascript.

But that's not a rabbit hole I'm ready to follow yet. I'll make a note about it.

Only returns the canvas if called from inside the window.

Apparently this didn't turn out very clear. This will only return None if called from a Web worker, it will always succeed if called from the "main thread" (the "window" context).

tim-blackbird · 2023-11-08T18:42:42Z

examples/app/return_after_run.rs

-//! - <https://docs.rs/bevy/latest/bevy/winit/struct.WinitSettings.html#structfield.return_from_run>
+//! not recommended because:
+//! - `App::run()` will never return on iOS and Web.
+//! - It is not possible to recreate a window afer the event loop has been terminated.


This is now a Bevy limitation, not winit's, right?

I believe so: related links:

Can't create event loop ondemand rust-windowing/winit#2431

Re-work event loop run APIs: adds run -> Result<>, run_ondemand and pump_events rust-windowing/winit#2767

tim-blackbird · 2023-11-08T18:55:23Z

examples/audio/audio_control.rs

-        if keyboard_input.just_pressed(KeyCode::Plus) {
+        if keyboard_input.just_pressed(KeyCode::NumpadAdd) {


What's up with Plus? Did it become Equal? but Equals already existed, hmmm

Not everyone has a numpad though, so should we use something else?

Not sure; I'll use equal.

These were swapped in winit by mistake IIRC :(

tim-blackbird · 2023-11-08T19:09:29Z

crates/bevy_input/src/keyboard.rs

+    // TOCLEAN: Thierry: this is originally SmolStr, but difficult to translate to FromReflect.
+    Web(SmolStr),


Is this comment up-to-date?

tim-blackbird · 2023-11-08T19:12:16Z

crates/bevy_window/src/cursor.rs

-    /// Program busy indicator.    
-    Wait,
-    /// Help indicator (often rendered as a "?")    
+


Not sure about all these empty lines.

I wanted to be as similar as the source, which was updated this way: https://github.com/rust-windowing/cursor-icon/blob/main/src/lib.rs

as cursor-icon was given its own dependency, maybe we could rely on that directly rather than copying it?

Also, licensing is probably not respected (and maybe other places too (see PR description "Call for help")), so I'm happy to discuss a better way of handling that.

Copying the message in winit's 'keyboard.rs' verbatim to our 'keyboard.rs' file(Where Key and KeyCode are defined) will satisfy the W3C license :)

from https://www.w3.org/copyright/software-license-2002/ ; I think we'd need to also include the changes made. they are pretty straightforward:

add Reflect capabilities

use another feature name for serialization

maybe not using non_exhaustive for enums?

But I lack knowledge on how to write that. I'll copy the licenses as I believe it's better than nothing :)

examples/audio/audio_control.rs

Vrixyz · 2023-11-22T17:27:43Z

I'm closing this PR in favor of #10702 ; which builds on this one but it's time to get a shorter comment thread

# Objective - Update winit dependency to 0.29 ## Changelog ### KeyCode changes - Removed `ScanCode`, as it was [replaced by KeyCode](https://github.com/rust-windowing/winit/blob/master/CHANGELOG.md#0292). - `ReceivedCharacter.char` is now a `SmolStr`, [relevant doc](https://docs.rs/winit/latest/winit/event/struct.KeyEvent.html#structfield.text). - Changed most `KeyCode` values, and added more. KeyCode has changed meaning. With this PR, it refers to physical position on keyboard rather than the printed letter on keyboard keys. In practice this means: - On QWERTY keyboard layouts, nothing changes - On any other keyboard layout, `KeyCode` no longer reflects the label on key. - This is "good". In bevy 0.12, when you used WASD for movement, users with non-QWERTY keyboards couldn't play your game! This was especially bad for non-latin keyboards. Now, WASD represents the physical keys. A French player will press the ZQSD keys, which are near each other, Kyrgyz players will use "Цфыв". - This is "bad" as well. You can't know in advance what the label of the key for input is. Your UI says "press WASD to move", even if in reality, they should be pressing "ZQSD" or "Цфыв". You also no longer can use `KeyCode` for text inputs. In any case, it was a pretty bad API for text input. You should use `ReceivedCharacter` now instead. ### Other changes - Use `web-time` rather than `instant` crate. (rust-windowing/winit#2836) - winit did split `run_return` in `run_onDemand` and `pump_events`, I did the same change in bevy_winit and used `pump_events`. - Removed `return_from_run` from `WinitSettings` as `winit::run` now returns on supported platforms. - I left the example "return_after_run" as I think it's still useful. - This winit change is done partly to allow to create a new window after quitting all windows: emilk/egui#1918 ; this PR doesn't address. - added `width` and `height` properties in the `canvas` from wasm example (#10702 (comment)) ## Known regressions (important follow ups?) - Provide an API for reacting when a specific key from current layout was released. - possible solutions: use winit::Key from winit::KeyEvent ; mapping between KeyCode and Key ; or . - We don't receive characters through alt+numpad (e.g. alt + 151 = "ù") anymore ; reproduced on winit example "ime". maybe related to rust-windowing/winit#2945 - (windows) Window content doesn't refresh at all when resizing. By reading rust-windowing/winit#2900 ; I suspect we should just fire a `window.request_redraw();` from `AboutToWait`, and handle actual redrawing within `RedrawRequested`. I'm not sure how to move all that code so I'd appreciate it to be a follow up. - (windows) unreleased winit fix for using set_control_flow in AboutToWait rust-windowing/winit#3215 ; ⚠️ I'm not sure what the implications are, but that feels bad 🤔 ## Follow up I'd like to avoid bloating this PR, here are a few follow up tasks worthy of a separate PR, or new issue to track them once this PR is closed, as they would either complicate reviews, or at risk of being controversial: - remove CanvasParentResizePlugin (#10702 (comment)) - avoid mentionning explicitly winit in docs from bevy_window ? - NamedKey integration on bevy_input: rust-windowing/winit#3143 introduced a new NamedKey variant. I implemented it only on the converters but we'd benefit making the same changes to bevy_input. - Add more info in KeyboardInput #10702 (review) - #9905 added a workaround on a bug allegedly fixed by winit 0.29. We should check if it's still necessary. - update to raw_window_handle 0.6 - blocked by wgpu - Rename `KeyCode` to `PhysicalKeyCode` #10702 (comment) - remove `instant` dependency, [replaced by](rust-windowing/winit#2836) `web_time`), we'd need to update to : - fastrand >= 2.0 - [`async-executor`](https://github.com/smol-rs/async-executor) >= 1.7 - [`futures-lite`](https://github.com/smol-rs/futures-lite) >= 2.0 - Verify license, see [discussion](#8745 (comment)) - we might be missing a short notice or description of changes made - Consider using https://github.com/rust-windowing/cursor-icon directly rather than vendoring it in bevy. - investigate [this unwrap](#8745 (comment)) (`winit_window.canvas().unwrap();`) - Use more good things about winit's update - #10689 (comment) ## Migration Guide This PR should have one.

few format tweaks, initially spotted working on bevyengine#8745

# Objective - Update winit dependency to 0.29 ## Changelog ### KeyCode changes - Removed `ScanCode`, as it was [replaced by KeyCode](https://github.com/rust-windowing/winit/blob/master/CHANGELOG.md#0292). - `ReceivedCharacter.char` is now a `SmolStr`, [relevant doc](https://docs.rs/winit/latest/winit/event/struct.KeyEvent.html#structfield.text). - Changed most `KeyCode` values, and added more. KeyCode has changed meaning. With this PR, it refers to physical position on keyboard rather than the printed letter on keyboard keys. In practice this means: - On QWERTY keyboard layouts, nothing changes - On any other keyboard layout, `KeyCode` no longer reflects the label on key. - This is "good". In bevy 0.12, when you used WASD for movement, users with non-QWERTY keyboards couldn't play your game! This was especially bad for non-latin keyboards. Now, WASD represents the physical keys. A French player will press the ZQSD keys, which are near each other, Kyrgyz players will use "Цфыв". - This is "bad" as well. You can't know in advance what the label of the key for input is. Your UI says "press WASD to move", even if in reality, they should be pressing "ZQSD" or "Цфыв". You also no longer can use `KeyCode` for text inputs. In any case, it was a pretty bad API for text input. You should use `ReceivedCharacter` now instead. ### Other changes - Use `web-time` rather than `instant` crate. (rust-windowing/winit#2836) - winit did split `run_return` in `run_onDemand` and `pump_events`, I did the same change in bevy_winit and used `pump_events`. - Removed `return_from_run` from `WinitSettings` as `winit::run` now returns on supported platforms. - I left the example "return_after_run" as I think it's still useful. - This winit change is done partly to allow to create a new window after quitting all windows: emilk/egui#1918 ; this PR doesn't address. - added `width` and `height` properties in the `canvas` from wasm example (bevyengine/bevy#10702 (comment)) ## Known regressions (important follow ups?) - Provide an API for reacting when a specific key from current layout was released. - possible solutions: use winit::Key from winit::KeyEvent ; mapping between KeyCode and Key ; or . - We don't receive characters through alt+numpad (e.g. alt + 151 = "ù") anymore ; reproduced on winit example "ime". maybe related to rust-windowing/winit#2945 - (windows) Window content doesn't refresh at all when resizing. By reading rust-windowing/winit#2900 ; I suspect we should just fire a `window.request_redraw();` from `AboutToWait`, and handle actual redrawing within `RedrawRequested`. I'm not sure how to move all that code so I'd appreciate it to be a follow up. - (windows) unreleased winit fix for using set_control_flow in AboutToWait rust-windowing/winit#3215 ; ⚠️ I'm not sure what the implications are, but that feels bad 🤔 ## Follow up I'd like to avoid bloating this PR, here are a few follow up tasks worthy of a separate PR, or new issue to track them once this PR is closed, as they would either complicate reviews, or at risk of being controversial: - remove CanvasParentResizePlugin (bevyengine/bevy#10702 (comment)) - avoid mentionning explicitly winit in docs from bevy_window ? - NamedKey integration on bevy_input: rust-windowing/winit#3143 introduced a new NamedKey variant. I implemented it only on the converters but we'd benefit making the same changes to bevy_input. - Add more info in KeyboardInput bevyengine/bevy#10702 (review) - bevyengine/bevy#9905 added a workaround on a bug allegedly fixed by winit 0.29. We should check if it's still necessary. - update to raw_window_handle 0.6 - blocked by wgpu - Rename `KeyCode` to `PhysicalKeyCode` bevyengine/bevy#10702 (comment) - remove `instant` dependency, [replaced by](rust-windowing/winit#2836) `web_time`), we'd need to update to : - fastrand >= 2.0 - [`async-executor`](https://github.com/smol-rs/async-executor) >= 1.7 - [`futures-lite`](https://github.com/smol-rs/futures-lite) >= 2.0 - Verify license, see [discussion](bevyengine/bevy#8745 (comment)) - we might be missing a short notice or description of changes made - Consider using https://github.com/rust-windowing/cursor-icon directly rather than vendoring it in bevy. - investigate [this unwrap](bevyengine/bevy#8745 (comment)) (`winit_window.canvas().unwrap();`) - Use more good things about winit's update - bevyengine/bevy#10689 (comment) ## Migration Guide This PR should have one.

update winit, fail compilation 👍

aaa3368

Vrixyz changed the title ~~Update winit to main~~ Update winit dependency to main Jun 2, 2023

alice-i-cecile added this to the 0.11 milestone Jun 2, 2023

alice-i-cecile requested a review from mockersf June 2, 2023 16:05

alice-i-cecile added A-Windowing Platform-agnostic interface layer to run your app in C-Dependencies A change to the crates that Bevy depends on M-Needs-Migration-Guide A breaking change to Bevy's public API that needs to be noted in a migration guide labels Jun 2, 2023

compiling ; but using physical key rather than virtual key

a93bf05

added logical key from winit ; removed ScanCode ; removed copy from I…

54483f9

…nput

Vrixyz commented Jun 4, 2023

View reviewed changes

examples/input/keyboard_input.rs Show resolved Hide resolved

Vrixyz added a commit to Vrixyz/bevy that referenced this pull request Jun 6, 2023

bevy_reflect: implement Reflect for SmolStr

cf33bdc

Prompted by winit's update bevyengine#8745.

Vrixyz mentioned this pull request Jun 6, 2023

bevy_reflect: implement Reflect for SmolStr #8771

Merged

alice-i-cecile added the S-Blocked This cannot move forward until something else changes label Jun 7, 2023

mockersf mentioned this pull request Jun 8, 2023

Rename keys like LAlt to AltLeft #8792

Merged

mockersf removed this from the 0.11 milestone Jun 8, 2023

Vrixyz added 2 commits June 9, 2023 09:27

Merge branch 'main' into update-winit

ae25abc

add a temporary comment to know the tested commit from winit main

ce707df

add nativekeycode ; fex fixes

dff33c3

local clippy CI fixes

4dcd03f

alice-i-cecile removed the S-Blocked This cannot move forward until something else changes label Oct 22, 2023

Vrixyz added 2 commits October 24, 2023 22:02

fix namedKey to their types

9c44f83

Merge branch 'main' of github.com:bevyengine/bevy into update-winit

9b0ea09

fix docs

9d038e7

Vrixyz mentioned this pull request Oct 25, 2023

few fmt tweaks #10264

Merged

github-merge-queue bot pushed a commit that referenced this pull request Oct 25, 2023

few fmt tweaks (#10264)

442a316

few format tweaks, initially spotted working on #8745

Vrixyz added 2 commits October 28, 2023 13:47

Merge branch 'main' into update-winit

a68a824

Merge branch 'main' of github.com:bevyengine/bevy into update-winit

dac9182

daxpedda mentioned this pull request Nov 1, 2023

Go back one page freezes the WASM runtime #10328

Open

ameknite pushed a commit to ameknite/bevy that referenced this pull request Nov 6, 2023

few fmt tweaks (bevyengine#10264)

f2a22fe

few format tweaks, initially spotted working on bevyengine#8745

Vrixyz added 2 commits November 8, 2023 16:43

Merge branch 'main' into update-winit

0aa4856

update accesskit to newly released crate version

bebfde0

fix process event api usage

66541a0

tim-blackbird reviewed Nov 8, 2023

View reviewed changes

Vrixyz commented Nov 8, 2023

View reviewed changes

examples/audio/audio_control.rs Outdated Show resolved Hide resolved

feedbacks from @devil-ira

c5de847

daxpedda mentioned this pull request Nov 22, 2023

Touch input is off on Y axis on WASM export #10694

Closed

Merge branch 'main' into update-winit

1318e23

Vrixyz mentioned this pull request Nov 22, 2023

Update winit dependency to 0.29 #10702

Merged

Vrixyz closed this Nov 22, 2023

Vrixyz mentioned this pull request Dec 21, 2023

Winit 0.29 follow up #11052

Closed

23 tasks

rdrpenguin04 pushed a commit to rdrpenguin04/bevy that referenced this pull request Jan 9, 2024

few fmt tweaks (bevyengine#10264)

8d13cf9

few format tweaks, initially spotted working on bevyengine#8745

		if keyboard_input.just_pressed(KeyCode::Plus) {
		if keyboard_input.just_pressed(KeyCode::NumpadAdd) {

		// TOCLEAN: Thierry: this is originally SmolStr, but difficult to translate to FromReflect.
		Web(SmolStr),

Update winit dependency to 0.29 #8745

Update winit dependency to 0.29 #8745

Conversation

Vrixyz commented Jun 2, 2023 • edited Loading

Objective

Changelog

Call for help

API complexity

Copy incompatible with SmolStr

Blockers

Follow up

Migration Guide

alice-i-cecile commented Jun 2, 2023

daxpedda commented Jun 3, 2023

Vrixyz commented Jun 3, 2023 • edited Loading

Vrixyz commented Jun 3, 2023 • edited Loading

alice-i-cecile commented Jun 3, 2023

Vrixyz commented Jun 8, 2023

github-actions bot commented Jun 9, 2023

github-actions bot commented Jun 9, 2023

github-actions bot commented Jun 9, 2023

github-actions bot commented Jun 9, 2023

alice-i-cecile commented Oct 22, 2023

simbleau commented Oct 25, 2023 • edited Loading

Vrixyz commented Oct 27, 2023 • edited Loading

Vrixyz commented Nov 8, 2023

tim-blackbird commented Nov 8, 2023

tim-blackbird left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Vrixyz Nov 8, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tim-blackbird Nov 8, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Vrixyz Nov 22, 2023 • edited Loading

Choose a reason for hiding this comment

Vrixyz commented Nov 22, 2023

Vrixyz commented Jun 2, 2023 •

edited

Loading

Vrixyz commented Jun 3, 2023 •

edited

Loading

Vrixyz commented Jun 3, 2023 •

edited

Loading

simbleau commented Oct 25, 2023 •

edited

Loading

Vrixyz commented Oct 27, 2023 •

edited

Loading

Vrixyz Nov 8, 2023 •

edited

Loading

tim-blackbird Nov 8, 2023 •

edited

Loading

Vrixyz Nov 22, 2023 •

edited

Loading