Keys now trigger actions on hold, not press

[ndarilek]

Hey, not sure if this is on bevy_egui's end or if I'll have to chase it through egui. I updated https://github.com/ndarilek/bevy_egui_a11y to work on Bevy 0.6. Formerly, pressing tab moved focus once. Now it seems to move focus rapidly.

It seems like some of these events are being triggered on hold rather than just on press. Focus should only move once when I press tab.

Thanks!

[ndarilek]

Sorry for the double post, but it just occurred to me that this might be happening on click as well (I.e. enter/space on an item may be generating multiple click events, and it should only generate one on press.) I'm getting lots of crashes, one of which involves multiple state transitions per frame. It occurs to me that this might be caused by multiple clicks generated when enter/space is pressed on an item, thus triggering multiple state transitions per frame when it shouldn't.

Thanks for the help so far.

[mvlabat]

Hi! There were changes in bevy_egui 0.6.2, which made bevy_egui listen for each keypress event that OS fires. The motivation for it was the following: imagine, you're typing something in a text field and decided to remove several characters by holding BACKSPACE. Before this change, you'd remove only 1 char, no matter how long you'd hold it, now bevy_egui will remove more than 1 character if you hold the button long enough, which is consistent with the majority of applications with UI. If you hold TAB in Google Chrome, for instance, you'll observe the same behaviour: the focus will be moved more than once.
So I'd say that this functionality works as intended.

I've a couple of questions related to your crashes though:

1. Is it bevy_egui causing the panic or your application? I couldn't reproduce it by holding TAB or SPACE while being focused on different widgets. Could you show me your backtrace?
2. Do you receive several events immediately during the same frame (even if you barely touch a button)? What is your desktop environment? On both Windows and macOS, which I use, there are configurable "Delay until repeat" and "Key repeat" settings. I believe every DE should support those and have sane defaults for them to prevent firing several keypress events during 1 frame.

[ndarilek]

Hello,

I definitely agree with keys continuing to trigger many actions when held. Backspace should of course clear a text edit field if held down long enough. And I can confirm that focus does indeed repeatedly move when holding down tab in Chrome.

But are we absolutely certain that a) Bevy's key repeat rate is tied to that of the OS vs. managed itself and b) that repeat rate is by default equal? Seems to me like there are different expectations for aa UI which needs to debounce key input a bit, vs. for a game that needs to consume it as quickly as possible.

To be clear, I'm not experiencing any crashes or panics. Nor am I claiming that I'm seeing multiple events per frame. It just seems like I have to tap tab way more quickly in my game to move focus a single spot, vs. in my OS where I don't have to be quite as fast. And while I respect and appreciate that I can change the key repeat delay, I don't think asking my players to do this will work out.

That said, I'm not sure what the best solution here might be. I'll try running my menus on a slower fixed timestep to see if that helps. I'd suggest slowing everything down, but that might make in-game UIs more sluggish too. Focus transitions definitely feel way too twitchy, though. I'd be interested in whether the same is true for sliders as well, though those would be harder for me to test since change events aren't propagated. But I think some sort of debounce somewhere makes sense.

[mvlabat]

But are we absolutely certain that a) Bevy's key repeat rate is tied to that of the OS vs. managed itself

Yeah, I believe this statement is true. Input events are handled by winit, and winit itself listens for OS events to handle keyboard input. There's simply no other source of that events. If we imagine that Bevy had its own rate of emitting the events, and it depended, let's say, on the framerate, it would behave really unreliably and in the worst case would lead to inconsistent or missed inputs. Such behaviour would require writing some additional logic and just makes less sense.
Btw, the fact that Bevy simply proxies OS events is also quite easy to confirm:
https://github.com/bevyengine/bevy/blob/514754d6503b2416e5266a24b39c884ab5d90d2f/crates/bevy_winit/src/lib.rs#L299

b) that repeat rate is by default equal?

Sorry, could you clarify this? Equal to what exactly? Like, whether it's constant and doesn't grow linearly, for instance?

It just seems like I have to tap tab way more quickly in my game to move focus a single spot, vs. in my OS where I don't have to be quite as fast.

This inconsistency might be related to the way you're handling the inputs. Are you iterating through all the events with EventReader<KeyboardInput> or simply using Input::pressed? The former depends on the OS repeat rate, while the latter is indeed affected by the framerate.

[ndarilek]

I've poked this a bit more, and I think there were a few things going on that made this look like a problem. Having fixed the other issues, this appears to have gone away.

Closing for now. If I'm still experiencing oddness, I'll open a new issue with more rigorous analysis.

Thanks a bunch, and sorry for the noise.

[mvlabat]

No worries, glad you were able to figure out what was the problem!