-
Notifications
You must be signed in to change notification settings - Fork 58
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
Correct delay for gestures #95
Conversation
…variable value. This corner case forces me to push my DLL060A:00 06CB:2734 trackpad really hard.
… and swipe4 gestures. Till now gestures were delayed, but delay was before any button down event, so after first gesture you had to "wait" for button down event, and button up was fired immediately after button down. It was like: 0 ms: gesture was made ... : delay for configured number of miliseconds x ms: send button down and button up events (othen multiple times). As a result actions bound to gestures via tools like xbindkeys were executed too late and othen more than once. This comes from fact that xserver can "see" generated events only when 'read_input' callback returns. To fix that I had to modify code to generate and "commit" buttown down events as fast as possible, and use timer to be able to fire delayed button up events. Actual flow looks like: 0 ms: gesture was made, button down ...: delay x ms: one button up event and so on. During development I merged code and data structures responsible for gestures configuration and execution. Two finger scroll, swipes and four finger swipes are now executed by same function. There are still some areas to merge, mostly in 'moving_update' and configuration code, but I didn't pushed it further right now. I also find and fixed bug with "ClickTime" property: it was set, but it wasn't used. Now taps will delay button up for configured amount of time. Be aware to not set it to higher value than tap to drag wait time. Otherwise delayed button up event may interrupt dragging.
What do you think about separate swipe click time for every direction? I think it's too complicated, I will reduce them to single click time property for every swipe type. |
…all four directions, but separate for gestures. I guess most users would set all four variables to one value. Also from this point delayed events will be fired early when user finish his gesture before even if it was scheduled for later. So my earlier notes about too high tap click time and tap to drag are no longer valid: button up event will be send right after releasing any of touches.
…elopment of swipes.
…wn for xserver and user as "Trackpad {Scroll,Swipe,Swipe4} Settings". Fixed bug in set_swipe_properties: now error code is handled correctly. Changed few variable names to follow convention.
There are an excessive number of changes in these few commits. I do not understand the reasons for the majority of them so I can't evaluate their necessity. In any case they conflict with the implementation of high precision scrolling which I'm working to get merged from another PR. I would prefer to have that as a feature prior to fixing this. At that point you will need to rebase your changes against the new dev branch. I would encourage you to make small changes across many commits and submit PRs with as few commits as possible. This is simply too much for me to follow. |
See commit message.
This resolve #78