suggested change to "swipe" recognizer #640

Closed
annam opened this Issue Aug 8, 2014 · 10 comments

Comments

Projects
None yet
9 participants
@annam
Contributor

annam commented Aug 8, 2014

Hello,

after upgrading to hammer v2 we noticed some inconsistencies in swipe detection:

for swipe to be triggered in v2 the velocity and direction are calculated from the last interval. so if you swipe but keep your finger on screen for a few milliseconds, velocity drops and direction may even be 'none'. this wasn't the case in v1, I haven't checked the code but the swipe listener was definitely more sensitive.

we've noticed that "swipe" is commonly (expected to be) triggered even after holding the finger down for some time after a swipe interaction, and this seems to be missed in v2.

we tried to override the velocity issue by using a negative velocity value, which unfortunately forces the swipe detection to disregard velocity all together but it's something that we can live with.

however to fix the direction "none" issue (or even wrong dimension if you slightly move your finger in any other direction while holding) we had to override the attrTest and emit functions of the swipe recognizer to use the offsetDirection value instead of the direction one. unfortunately this means we'll miss any updates to the swipe recognizer unless we compare and add them to our own overrides. it would be great if you cared to integrate this into the master hammer.js!

tnx!

@runspired

This comment has been minimized.

Show comment
Hide comment
@runspired

runspired Aug 12, 2014

Contributor

+1

Contributor

runspired commented Aug 12, 2014

+1

@jtangelder

This comment has been minimized.

Show comment
Hide comment
@jtangelder

jtangelder Aug 12, 2014

Member

Could you create a PR for these changes?

Member

jtangelder commented Aug 12, 2014

Could you create a PR for these changes?

@tosca

This comment has been minimized.

Show comment
Hide comment
@tosca

tosca Aug 14, 2014

I am so sorry to bother you, but you are the experts and I have been
working on this for 3 weeks. Before I 'punt', I would like to know if
hammer.js versoin 1/**works with multiple carousels on multiple bootstrap
nav-tabs pages. I can get multiple carousels to swipe independently on one
single page, but not on a one page tab container.
* super simple carousel
* animation between panes happens with css transitions
*/
function Carousel(element)
{ etc...

http://rickmaxwell.apphb.com/#!work

I do have hammer working on my website build, but when tabbing to another
"WORK" catagory, the images are images render 100px wide across the
screen... BUT work perfectly when you resize the browser window,
(naturally, you cannot resize phones and tablets, but if you swipe enough
times, the single img fills the screen.

Oddly, the first carousel in the WORKS catagory works perfectly, but the
tab-click to the second catagory, returns a "pane" element that is always
100px wide, initially, until you resize the screen.

Does hammer.js ver 1, support multiple carousels in separate tab-pane
containers?

I am eternally grateful.

Thank you and njoy!

Tosca Ragnini
tosca.ragnini@gmail.com
630.248.1990

http://www.toscatech.net%20 www.toscatech.net

On Tue, Aug 12, 2014 at 4:55 AM, Jorik Tangelder notifications@github.com
wrote:

Could you create a PR for these changes?


Reply to this email directly or view it on GitHub
#640 (comment).

tosca commented Aug 14, 2014

I am so sorry to bother you, but you are the experts and I have been
working on this for 3 weeks. Before I 'punt', I would like to know if
hammer.js versoin 1/**works with multiple carousels on multiple bootstrap
nav-tabs pages. I can get multiple carousels to swipe independently on one
single page, but not on a one page tab container.
* super simple carousel
* animation between panes happens with css transitions
*/
function Carousel(element)
{ etc...

http://rickmaxwell.apphb.com/#!work

I do have hammer working on my website build, but when tabbing to another
"WORK" catagory, the images are images render 100px wide across the
screen... BUT work perfectly when you resize the browser window,
(naturally, you cannot resize phones and tablets, but if you swipe enough
times, the single img fills the screen.

Oddly, the first carousel in the WORKS catagory works perfectly, but the
tab-click to the second catagory, returns a "pane" element that is always
100px wide, initially, until you resize the screen.

Does hammer.js ver 1, support multiple carousels in separate tab-pane
containers?

I am eternally grateful.

Thank you and njoy!

Tosca Ragnini
tosca.ragnini@gmail.com
630.248.1990

http://www.toscatech.net%20 www.toscatech.net

On Tue, Aug 12, 2014 at 4:55 AM, Jorik Tangelder notifications@github.com
wrote:

Could you create a PR for these changes?


Reply to this email directly or view it on GitHub
#640 (comment).

@annam

This comment has been minimized.

Show comment
Hide comment
@annam

annam Aug 14, 2014

Contributor

Sure i'll create a PR for this next week!

Contributor

annam commented Aug 14, 2014

Sure i'll create a PR for this next week!

@bmesing

This comment has been minimized.

Show comment
Hide comment
@bmesing

bmesing Sep 10, 2014

+1
The current implementation make swiping almost unusable: The velocity is calculated only for a certain last interval, i.e. if you slow down at the very end of your gesture (as one often does especially with a mouse), swiping will not work.

bmesing commented Sep 10, 2014

+1
The current implementation make swiping almost unusable: The velocity is calculated only for a certain last interval, i.e. if you slow down at the very end of your gesture (as one often does especially with a mouse), swiping will not work.

@alexandberg

This comment has been minimized.

Show comment
Hide comment

+1

@src-code

This comment has been minimized.

Show comment
Hide comment
@src-code

src-code Sep 25, 2014

+1 Glad to see this addressed in PR #669, it makes it difficult to recognize aborted pans/swipes as well (eg, user swipes a carousel left, but then starts to swipe right before releasing... normally you could compare direction and offsetDirection, but a momentary hesitation causes direction == none)

+1 Glad to see this addressed in PR #669, it makes it difficult to recognize aborted pans/swipes as well (eg, user swipes a carousel left, but then starts to swipe right before releasing... normally you could compare direction and offsetDirection, but a momentary hesitation causes direction == none)

@akruis

This comment has been minimized.

Show comment
Hide comment
@akruis

akruis Oct 2, 2014

I just tried PR #669 and get much better results on iOS.

  • 1 for this PR.

p.s. and many many thanks for providing hammer.

akruis commented Oct 2, 2014

I just tried PR #669 and get much better results on iOS.

  • 1 for this PR.

p.s. and many many thanks for providing hammer.

@anitapillai

This comment has been minimized.

Show comment
Hide comment
@anitapillai

anitapillai Dec 12, 2014

The current implementation make swiping almost unusable on Desktops. PR #669 fixes the issue

The current implementation make swiping almost unusable on Desktops. PR #669 fixes the issue

@runspired

This comment has been minimized.

Show comment
Hide comment
@runspired

runspired Aug 7, 2015

Contributor

Closing in favor of #806

Contributor

runspired commented Aug 7, 2015

Closing in favor of #806

@runspired runspired closed this Aug 7, 2015

arschmitz added a commit that referenced this issue Aug 8, 2015

stop swipe from triggering after multitouch gesture
if after pinch/rotate, one finger touchends before the other, swipe is
incorrectly triggered because the last gesture is a single-touch
gesture. this checked for maximum pointers in gesture

Fixes #640
Ref #639
Ref #806
Closes #669
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment