You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With any widget, such as a Button or Label, .clicked() events are not recognized when the screen is tapped once. Instead, a single tap triggers long_touched() after a delay. Tapping twice in a quick succession generates a clicked() followed by a long_touched().
I did some further digging and found that we were not getting WindowEvent::Touch events from winit with TouchPhase::Ended when finger was lifted from the screen. Instead, the event would get sent together with the next TouchPhase::Started.
I confirmed the behavior happens with winit example code (no egui involved) on v0.30.2. Tested later versions and found that the issue was fixed in winit v0.30.4.
For funsies, I kept digging into winit changes, and it's likely that bumping to a newer smithay-client-toolkit fixed it (which brought in Smithay/client-toolkit@8708dd5). I didn't retest to confirm the exact root cause, but that's likely it.
So once egui switches to winitv0.30.4 or later, this issue should resolve itself. Looks like it is currently pinned to v0.30.2 as per #4849. Looks like the fix for that might be ready to go as of today, and #4939 might bring it in!
Describe the bug
With any widget, such as a
Button
orLabel
,.clicked()
events are not recognized when the screen is tapped once. Instead, a single tap triggerslong_touched()
after a delay. Tapping twice in a quick succession generates aclicked()
followed by along_touched()
.To Reproduce
Cargo.toml
:src/main.rs
:Steps to reproduce the behavior:
cargo run
the above codeExpected behavior
clicked()
gets shown on the screen.Screenshots
This can also be reproduced by
egui_demo_app
, built from latestmaster
(d856f7b), by opening "Input Test" and tapping on "Sense::click" label:Desktop:
(I tested on Windows, on a slightly different touchscreen-equipped Lenovo laptop, and it works correctly there.)
Additional context
This might be related to the observations found in #4668 ?
I bisected the behavior using
egui_demo_app
: last working commit is 8503a85, and it breaks at 8e5959d.The text was updated successfully, but these errors were encountered: