search

marsqing / libinput-three-finger-drag

Three-finger-drag support for libinput
MIT License
87 stars 11 forks source link

Added some niceties #6

Closed JacksonWrath closed 2 years ago

JacksonWrath commented 2 years ago

I forked this for some quality-of-life improvements I wanted to make. Here they are in case you'd like them as well!

marsqing commented 2 years ago

Looks good, a little question, why not do "xdo.mouse_up(1).unwrap()" in GESTURE_SWIPE_END?

JacksonWrath commented 2 years ago

That's part of the "continue dragging after raising fingers" commit. GESTURE_SWIPE_END is sent as soon as you lift your fingers, so if you start dragging again it'll reset. Not a huge deal for moving windows or scrollbars, but causes you to unhighlight things or drop a file/other draggable too early when you lift your fingers.

It's not perfect, for sure; I wrote it to just not send mouse_up until any other mouse input is received. There's some edge cases where leaving the mouse down because the user never moved it again causes weird behavior (e.g. drag-and-drop). I was honestly just too lazy to write up a timer with callback that would send mouse_up after some specified delay for myself.

Now that I'm talking about it though, I'll probably go add the timer. If this PR is still open when I get around to that, I'll update it.

JacksonWrath commented 2 years ago

Had to make some more significant changes to send XDo commands on a timer. I'm new to Rust, so if there's a better way to do this, I'm open to suggestions!

marsqing commented 2 years ago

Is it ok to do nothing at line 89 so we can save cpu on non-gesture events?

JacksonWrath commented 2 years ago

Ha, okay so, in looking into the CPU usage, I found a small bug in the intended behavior of ignoring accidental GESTURE_HOLD events. Pushed a fix for that.

We can't do nothing at that line without reverting the ability to reposition fingers while dragging. That line is there because of the mouse_up_delay. If you move the pointer before the delay finishes, it needs to immediately send a mouse_up event so you don't drag futher than you intended.

That said, I tested with this line removed and CPU was the same (in htop at least, within 0.1%). All it's doing on most events is a few conditional statements. It only actually sends the mouse_up to libxdo if it's currently in the middle of a drag; otherwise it just returns immediately back to the main loop. I believe the bulk of CPU is spent on the string find and libinput debug-events.

JacksonWrath commented 2 years ago

I'm actually already considering if this could be done with the actual libinput bindings instead of debug-events to see what effect that has on CPU, but I'll play with that on another branch and let you know if it has a positive result.

marsqing commented 2 years ago

Nice work! Also the libinput binding solution would be much better than the current implementation. Look forward to that!