Skip to content
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

Closed
wants to merge 6 commits into from
Closed

Conversation

p2rkw
Copy link

@p2rkw p2rkw commented Jul 15, 2015

See commit message.

This resolve #78

vanilla-wow-addons and others added 3 commits July 10, 2015 21:25
…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.
@p2rkw
Copy link
Author

p2rkw commented Jul 15, 2015

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.

p2rkw added 3 commits July 15, 2015 23:26
…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.
…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.
@rynbrd
Copy link
Owner

rynbrd commented Jul 27, 2015

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.

@p2rkw p2rkw closed this Nov 6, 2016
@p2rkw p2rkw deleted the unrepetable_swipes branch November 6, 2016 22:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Delay between Swipes
3 participants