Conversation
When a move event fired immediately after a press a checkDirection was done and the isVertical check sometimes inconsistently calculated. This makes the swipe direction always follow the mouse drag.
rcoup
left a comment
rcoup
left a comment
There was a problem hiding this comment.
helper.py change/revert commits need to be rebased away too.
| # the moveEvent was fired immediately after the press event, | ||
| # don't change the swipe direction | ||
| return | ||
|
|
There was a problem hiding this comment.
I wonder if it's better to move this further down?
I think the issue is that dX=0; dY=0, then isVertical is set to False always, even if it was True before? Whereas maybe we should if not dX and not dY: return at that point?
There was a problem hiding this comment.
It also seems to happen depending on where the first click is and you can end up with a dX > dY. I'm not totally clear on all the conditions where it happened but it was at least some times where the values were non-zero and it got stuck as True. The case that I ran into this was that the swipe would always turn vertical and stay that way.
Re-thinking this... that explanation isn't so clear around how it initially came to my attention but there are cases where the move event came where the first point and even point were the same so I wanted to bail out completely there. I suspect there are other cases as well.
There was a problem hiding this comment.
On helper.py, yes will need the rebase, just depends on the order that these might be applied.
2 participants
When a move event fired immediately after a press a checkDirection was done
and the isVertical check sometimes inconsistently calculated. This makes the
swipe direction always follow the mouse drag.