Skip to content

bevy_winit(emit raw winit events) #15884

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Dec 3, 2024

Conversation

HugoPeters1024
Copy link
Contributor

@HugoPeters1024 HugoPeters1024 commented Oct 13, 2024

Objective

  • Exposes raw winit events making Bevy even more modular and powerful for custom plugin developers (e.g. a custom render plugin).

XRef: #5977
It doesn't quite close the issue as sending events is not supported (or not very useful to be precise). I would think that supporting that requires some extra considerations by someone a bit more familiar with the bevy_winit crate. That said, this PR could be a nice step forward.

Solution

Emit RawWinitWindowEvent objects for each received event.

Testing

I verified that the events are emitted using a basic test app. I don't think it makes sense to solidify this behavior in one of the examples.


Showcase

My example usage for a custom egui_winit integration:

for ev in winit_events.read() {
    if ev.window_id == window.id {
        let _ = egui_winit.on_window_event(&window, &ev.event);
    }
}

@alice-i-cecile alice-i-cecile added this to the 0.16 milestone Oct 13, 2024
@alice-i-cecile alice-i-cecile added A-Windowing Platform-agnostic interface layer to run your app in C-Usability A targeted quality-of-life change that makes Bevy easier to use X-Contentious There are nontrivial implications that should be thought through D-Straightforward Simple bug fixes and API improvements, docs, test and examples S-Needs-Review Needs reviewer attention (from anyone!) to move forward labels Oct 13, 2024
@HugoPeters1024 HugoPeters1024 force-pushed the hp/raw-winit-events branch 4 times, most recently from cefe74a to 0606734 Compare October 14, 2024 08:16
Copy link
Contributor

@BenjaminBrienen BenjaminBrienen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only a tiny nit! Just change one of them (whichever doesn't follow the typical usage).

@HugoPeters1024
Copy link
Contributor Author

I rebased to hopefully get the CI fix for mac os screenshots

Copy link
Member

@tychedelia tychedelia left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not so sure that just doing a plain copy is the best way, esp since 99% of users won't use this, but I did just run into a situation with egui as well that requires the underlying winit events.

@HugoPeters1024
Copy link
Contributor Author

Not so sure that just doing a plain copy is the best way, esp since 99% of users won't use this, but I did just run into a situation with egui as well that requires the underlying winit events.

Thanks for the review. I acknowledge that indeed most users would not and probably should not use this. But it can be a powerful escape hatch as many 3rd party packages take raw egui events as input.

@tychedelia tychedelia added S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it and removed S-Needs-Review Needs reviewer attention (from anyone!) to move forward labels Nov 25, 2024
@tychedelia
Copy link
Member

Another alternative would be to provide a way to convert bevy events back into winit events. I'm doing this in my project and it seems to work okay, although is a lossy process w.r.t. some of the original event information.

@alice-i-cecile alice-i-cecile added this pull request to the merge queue Dec 3, 2024
Merged via the queue into bevyengine:main with commit b9cc6e1 Dec 3, 2024
28 checks passed
ecoskey pushed a commit to ecoskey/bevy that referenced this pull request Jan 6, 2025
# Objective

- Exposes raw winit events making Bevy even more modular and powerful
for custom plugin developers (e.g. a custom render plugin).

XRef: bevyengine#5977
It doesn't quite close the issue as sending events is not supported (or
not very useful to be precise). I would think that supporting that
requires some extra considerations by someone a bit more familiar with
the `bevy_winit` crate. That said, this PR could be a nice step forward.

## Solution

Emit `RawWinitWindowEvent` objects for each received event.

## Testing

I verified that the events are emitted using a basic test app. I don't
think it makes sense to solidify this behavior in one of the examples.

---

## Showcase

My example usage for a custom `egui_winit` integration:

```rust
for ev in winit_events.read() {
    if ev.window_id == window.id {
        let _ = egui_winit.on_window_event(&window, &ev.event);
    }
}
```

---------

Co-authored-by: IceSentry <[email protected]>
github-merge-queue bot pushed a commit that referenced this pull request Mar 31, 2025
…rce (#18644)

# Objective

- In the latest released version (15.3) I am able to obtain this
information by getting the actual `EventLoop` via `non_send_resource`.
Now that this object has (probably rightfully so) been replaced by the
`EventLoopProxy`, I can no longer maintain my custom render backend:
https://github.com/HugoPeters1024/bevy_vulkan. I also need the display
handle for a custom winit integration, for which I've made patches to
bevy before: XREF: #15884


## Solution

- Luckily, all that is required is exposing the `OwnedDisplayHandle` in
its own wrapper resource.

## Testing

- Aforementioned custom rendering backend works on this commit.

---------

Co-authored-by: HugoPeters1024 <[email protected]>
mockersf pushed a commit that referenced this pull request Mar 31, 2025
…rce (#18644)

# Objective

- In the latest released version (15.3) I am able to obtain this
information by getting the actual `EventLoop` via `non_send_resource`.
Now that this object has (probably rightfully so) been replaced by the
`EventLoopProxy`, I can no longer maintain my custom render backend:
https://github.com/HugoPeters1024/bevy_vulkan. I also need the display
handle for a custom winit integration, for which I've made patches to
bevy before: XREF: #15884


## Solution

- Luckily, all that is required is exposing the `OwnedDisplayHandle` in
its own wrapper resource.

## Testing

- Aforementioned custom rendering backend works on this commit.

---------

Co-authored-by: HugoPeters1024 <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Windowing Platform-agnostic interface layer to run your app in C-Usability A targeted quality-of-life change that makes Bevy easier to use D-Straightforward Simple bug fixes and API improvements, docs, test and examples S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it X-Contentious There are nontrivial implications that should be thought through
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants