Changing direction during pan not recognised

[benaadams]

Fix for changing direction during pan not being recognised.

e.g. http://stackoverflow.com/questions/21905554/detect-the-direction-change-on-hammer-js-event

Currently deltaX and deltaY don't reverse until the input passes the start of pan

[DimitryDushkin]

I've tried this fix, it broke 'pan'.

[runspired]

You could keep track of the position change since the last change yourself, for instance (using the dom events version);

var previousDelta = {
    x : 0,
    y : 0
};

jQuery('#myElement').on('panStart', function(e) {
   previousDelta.x = 0;
   previousDelta.y = 0;
});
jQuery('#myElement').on('pan', function(e) {
    var currentDeltas = {
        x : e.deltaX - previousDelta.x,
        y : e.deltaY - previousDelta.y: 
    };

   //do something based on the current delta values

    previousDelta.x = e.deltaX;
    previousDelta.y = e.deltaY;
});

[runspired]

@arschmitz I would close this as not a bug. The deltas are distance from the origin event (and should be), there is a direction attribute already, and you can keep track of smaller deltas yourself as needed.

I do, however, think having both an originDelta and a currentDelta would be helpful for using Hammer as a primitive with physics based gestures. It makes it much easier to calculate momentum at release.

[arschmitz]

I agree maybe open a new issue for discussion on that?

[arschmitz]

closing this in favor of #806

[benaadams]

My issue was it didn't pan back until you'd passed the origin so pan drags were uni-directional rather than responsive. e.g. based on max extent rather than current relative position from origin.

[arschmitz]

@benaadams ok so i think that potentially makes sense and is worth considering as it should be a simple change. I'm going to reopen this for more discussion.

So to clarify you believe we should report the current distance from the origin vs the max distance ( as it does now )

[benaadams]

Yes, so it follows you finger rather than being a single direction/locking event

[arschmitz]

@benaadams would you be interested in updating this to not break pan but still fix the issue?

[benaadams]

I'm not entirely sure how it broke the pan; though I'm only testing on pointer event devices? Whereas it seemed broken before.

Checking my assumption: Pan should follow finger, if you move left it should go left, if you start going right it should start moving back - so your finger is always above the bit that is moving? Previously it would lock and only start going back once you passed the origin of the gesture start.

[arschmitz]

@benaadams not sure but guessing if you fix the test failures it will fix pan.

Semi related if you are experiencing issues with pointer events devices please report them we do have test devices now and will make sure these issues are fixed.

Pointer events are the direction we plan on taking this library and are top priority. We even have members of the pointer events working group and browser vendors helping in this respect with the project and are working with PEP the team ( pointer events polyfill ).

[runspired]

I revisited this, and reconfirmed by original belief that this is not a bug.

Currently, the delta is the distance from the original event, not the last event. While it is useful to have a "current delta", that can be done on your own currently, and should become a feature in the next minor.

E.G. as stated earlier:

I think having both an originDelta and a currentDelta would be helpful for using Hammer as a primitive with physics based gestures. It makes it much easier to calculate momentum at release.

[benaadams]

The issue I was experiencing is it wasn't the the correct delta from the origin event; rather the furthest delta from the origin event; so if I moved +5 X; delta would be +5 X; if I then moved -1 X, the delta would still be +5 X; rather than +4 X

[runspired]

I've confirmed that's not the case, you had to have been dealing with a cached event or some such.

[benaadams]

Might have been using it wrong; sounds like I was using the delta delta from the feedback