Page MenuHomePhabricator

efl/gesture: correctly handle pointer going off canvas during gestures
AbandonedPublic

Authored by zmike on Jan 8 2020, 11:44 AM.

Details

Summary

this should immediately cancel an existing gesture and then ignore new
events until the pointer is once again on the canvas

Depends on D11029

Diff Detail

Repository
rEFL core/efl
Branch
master
Lint
Lint OK
Unit
No Unit Test Coverage
Build Status
Buildable 15513
zmike created this revision.Jan 8 2020, 11:44 AM

It seems that this patch has no reviewers specified. If you are unsure who can review your patch, please check this wiki page and see if anyone can be added: https://phab.enlightenment.org/w/maintainers_reviewers/

zmike requested review of this revision.Jan 8 2020, 11:44 AM
zmike added a child revision: D11053: efl/gesture: formatting.
cedric added a subscriber: woohyun.

I am not sure we want this behavior, maybe @woohyun or someone else in Korea would have an opinion on this.

zmike updated this revision to Diff 28130.Jan 13 2020, 12:12 PM
zmike edited the summary of this revision. (Show Details)

rebase

CHAN requested changes to this revision.Jan 16 2020, 9:03 PM
CHAN added a subscriber: CHAN.

@zmike Thank you for the commit.

In the previous gesture layer and other platform behaviors, by default, if flick is started inside the target object,
it will track even if the mouse event is outside the target area. :(

Although this patch seems meaningful to me it does not seem to be compatible with the existing behavior learned by the user.

This revision now requires changes to proceed.Jan 16 2020, 9:03 PM
zmike added a comment.Jan 17 2020, 6:11 AM
In D11052#210253, @CHAN wrote:

@zmike Thank you for the commit.

In the previous gesture layer and other platform behaviors, by default, if flick is started inside the target object,

it will track even if the mouse event is outside the target area. :(

Although this patch seems meaningful to me it does not seem to be compatible with the existing behavior learned by the user.

This patch attempts to bring parity to running on a desktop vs a touch screen. If you flick a finger off the display of a touch screen, you cannot continue to receive events.

If we don't want this then that's fine as well, and thanks for checking.

zmike added a comment.Jan 21 2020, 9:50 AM

@CHAN Do you have any further comments on this?

zmike updated this revision to Diff 28333.Jan 21 2020, 11:55 AM
zmike added a reviewer: bu5hm4n.

rebase/update

CHAN added a comment.Jan 21 2020, 10:17 PM

@zmike Thanks you

In my opinion, If the starting point of the flick event is inside the target object, it would be better to keep the concept of recognizing it as a flick gesture, even if the event after that is outside the target object.

zmike abandoned this revision.Jan 22 2020, 5:56 AM

Alright, I'll take this one out of the series. Thanks for your feedback!