Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Allow read-write access to raw WindowEvents within Bevy apps #5977

Open
alice-i-cecile opened this issue Sep 13, 2022 · 4 comments
Open

Allow read-write access to raw WindowEvents within Bevy apps #5977

alice-i-cecile opened this issue Sep 13, 2022 · 4 comments
Labels
A-Input Player input via keyboard, mouse, gamepad, and more A-Windowing Platform-agnostic interface layer to run your app in C-Testing A change that impacts how we test Bevy or how users test their apps C-Usability A targeted quality-of-life change that makes Bevy easier to use D-Modest A "normal" level of difficulty; suitable for simple features or challenging fixes S-Needs-Design This issue requires design work to think about how it would best be accomplished

Comments

@alice-i-cecile
Copy link
Member

What problem does this solve or what need does it fill?

While working on an input capture and playback library, @plof27 pointed out that I may be able to capture raw events from winit directly, rather than dealing with the separated event streams.

Unfortunately, the necessary WindowEvent type is not exposed in winit_runner_with, our winit-based app runner.

What solution would you like?

  1. Allow users to read the full list of raw window events sent.
  2. Allow users to send raw window events from within systems, which are then processed by the winit loop.

These should be exposed as a simple Events<WindowEvent>; the complexity comes from ensuring that winit_runner_with responds appropriately.

What alternative(s) have you considered?

I've considered exposing this with a custom runner, however #4537 means this is a tedious and duplication-heavy task.
@alice-i-cecile alice-i-cecile added A-Input Player input via keyboard, mouse, gamepad, and more 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 C-Testing A change that impacts how we test Bevy or how users test their apps labels Sep 13, 2022
@alice-i-cecile alice-i-cecile changed the title Allow read-write raw WindowEvents within Bevy apps Allow read-write access to raw WindowEvents within Bevy apps Sep 13, 2022
@alice-i-cecile
Copy link
Member Author

This is blocked on rust-windowing/winit#1387, as WindowEvent has a mostly pointless lifetime that means we can't effectively store this data without some serious cludgery. Fix is proposed in ttps://github.com/rust-windowing/winit/pull/1456 / , but the PR is very dead.

@alice-i-cecile alice-i-cecile added S-Blocked This cannot move forward until something else changes and removed S-Blocked This cannot move forward until something else changes labels Sep 13, 2022
@alice-i-cecile
Copy link
Member Author

This isn't quite blocked, the WindowEvent::to_static method exists, and thus WindowEvent<'static> can be used safely. However the problematic variant (scale factor changing) cannot be represented.

@JamesHovet
Copy link

Just wanted to chime in and give a +1 to this issue. I recently went down the same rabbit hole of wanting to access raw events before the winit runner had the chance to convert them into bevy events and was unable to do so.

(in my case because I wanted to pass the raw events to egui-winit so that I could use egui without using the bevy renderer and a crate like bevy_egui, but that's beside the point)

I think the interface that would have been most ergonomic for me would be to have been able to pass in an "intercept" function that took in winit window events and done whatever processing I wanted with them and then returned a boolean indicating if that event should be propagated down to the winit-runner or not.

@B-head B-head mentioned this issue Jul 4, 2023
Draft
8 tasks
@HugoPeters1024
Copy link
Contributor

HugoPeters1024 commented Oct 13, 2024 •
edited
Loading

I would also like to +1 this, especially the read access. My use case is for a custom rendering backend that implements egui support transitively via egui_winit (egui_bevy is unfortunately tightly coupled with Bevy's default rendering backend).

So in general, Bevy could be even more modular by exposing winit events directly. I don't see any particular problem with this for the following reasons:

  1. it's very easy to implement, just a few extra lines of code in bevy_winit (the lifetime problems described in previous comments didn't come up for me, winit::event::WindowEvent can just be clone()-ed)
  2. Of course it can be a footgun as most users should not look at these events, but they could be discouraged from using it by wrapping in some aptly named RawWinitEvent struct.

@alice-i-cecile alice-i-cecile added S-Needs-Design This issue requires design work to think about how it would best be accomplished D-Modest A "normal" level of difficulty; suitable for simple features or challenging fixes labels Oct 13, 2024
@HugoPeters1024 HugoPeters1024 mentioned this issue Oct 13, 2024
Merged
github-merge-queue bot pushed a commit that referenced this issue Dec 3, 2024
@HugoPeters1024 @IceSentry
bevy_winit(emit raw winit events) (#15884)
b9cc6e1 
# 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:

```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]>
ecoskey pushed a commit to ecoskey/bevy that referenced this issue Jan 6, 2025
@HugoPeters1024 @IceSentry @ecoskey
bevy_winit(emit raw winit events) (bevyengine#15884)
72ebc94 
# 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]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-Input Player input via keyboard, mouse, gamepad, and more A-Windowing Platform-agnostic interface layer to run your app in C-Testing A change that impacts how we test Bevy or how users test their apps C-Usability A targeted quality-of-life change that makes Bevy easier to use D-Modest A "normal" level of difficulty; suitable for simple features or challenging fixes S-Needs-Design This issue requires design work to think about how it would best be accomplished
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@alice-i-cecile @JamesHovet @HugoPeters1024