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.

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

set KeyboardInput::repeat to true for forwarded repeat events #16

Open
cxreiff opened this issue Jul 17, 2024 · 3 comments
Open

set KeyboardInput::repeat to true for forwarded repeat events #16

cxreiff opened this issue Jul 17, 2024 · 3 comments

Comments

@cxreiff
Copy link
Collaborator

cxreiff commented Jul 17, 2024

Bevy merged a PR adding a repeat boolean to the KeyboardInput struct, corresponding to an equivalent concept in winit. When forwarding crossterm events we should correctly set this flag when reported by the terminal or we can reasonably identify a repeat event as part of our emulation strategy.

Holding off on a PR until events are refactored, just opening this to keep this bevy input change on the radar as I'm not sure if it will be mentioned in 0.15 migration materials.

(Side conversation: how should changes like this and the event refactor, that depend on unreleased changes in bevy, be handled with release-plz? Should a separate 0.15 branch be kept?)

@joshka
Copy link
Owner

joshka commented Jul 17, 2024

I'd prefer to keep it simple when possible (and avoid getting into the release engineering game). Try to avoid chasing unreleased features too hard like this unless there's a great need to do so. The problem with having multiple release branches is that it becomes cumbersome to track which one is accurate and keep them up to date, and backport fixes, and ....

Instead I'd generally leave a PR that depends on an upstream fix open until it can be merged after release.

This is not a hard and fast rule, but it's one that leads to less time spent.

@cxreiff
Copy link
Collaborator Author

cxreiff commented Jul 17, 2024

With you on that. Leaving it up to you whether to keep this issue open and I'll revisit come official release time.

@joshka
Copy link
Owner

joshka commented Jul 17, 2024

Keep it open - it's worth knowing that this will come up in the next release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants