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
{{ message }}
This repository has been archived by the owner on Nov 1, 2021. It is now read-only.
I am writing a program and I had it use right click as a means of exiting the event loop. I was trying to validate my serial to initiate a drag and drop and noticed that the serial in sway debug logs weren't being validated, but the button_count also seemed incorrect. It also kept incrementing.
I realized that by using right click to exit the program, button_count wasn't being decremented.
Tracking increments and decrements seems like it is a difficult balance act and could easily get corrupted if we encounter a state which is unaccounted for, so it seems like there needs to be an appropriate point at which we should resetbutton_count so as to at least have a catch-all in case we screw up.
In this case, if the surface originating a pointer event is destroyed, then it makes sense to reset the state.
wlroots has migrated to gitlab.freedesktop.org. This issue has been moved to:
In addition to `button_count`, we keep track of the current buttons
pressed just as in `wlr_keyboard`.
Add `set_add` and `set_remove` to assist with this. These functions can
only be used with values greater than 0 (such as the button/key masks
for keyboards and pointers).
Partially addresses:
- #1716
- #1593
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I am writing a program and I had it use right click as a means of exiting the event loop. I was trying to validate my serial to initiate a drag and drop and noticed that the serial in sway debug logs weren't being validated, but the button_count also seemed incorrect. It also kept incrementing.
I realized that by using right click to exit the program,
button_count
wasn't being decremented.Tracking increments and decrements seems like it is a difficult balance act and could easily get corrupted if we encounter a state which is unaccounted for, so it seems like there needs to be an appropriate point at which we should reset
button_count
so as to at least have a catch-all in case we screw up.In this case, if the surface originating a pointer event is destroyed, then it makes sense to reset the state.
wlroots has migrated to gitlab.freedesktop.org. This issue has been moved to:
https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/1716
The text was updated successfully, but these errors were encountered: