this is always a full iteration so we don't actually need a list
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D11241
these objects need to be cleaned up immediately outside of event
processing to avoid having them automatically deleted later on and
triggering a double delete
Differential Revision: https://phab.enlightenment.org/D11240
this adds support for creating custom (out of tree) gesture recognizers by
adding an abstract recognizer class that can be inherited and reused
docs TBA
Reviewed-by: woochan lee <wc0917.lee@samsung.com>
Differential Revision: https://phab.enlightenment.org/D11223
this exposes internal objects that we shouldn't be exposing
Reviewed-by: woochan lee <wc0917.lee@samsung.com>
Differential Revision: https://phab.enlightenment.org/D11221
if we have not begun to process a zoom gesture by this point, then we should
not be emitting a cancel result
Reviewed-by: woochan lee <wc0917.lee@samsung.com>
Differential Revision: https://phab.enlightenment.org/D11208
cancel is used to indicate that a gesture which has begun to trigger has been
canceled, so if we have already canceled then we should not re-cancel here
Reviewed-by: woochan lee <wc0917.lee@samsung.com>
Differential Revision: https://phab.enlightenment.org/D11207
we only care about the last touch unpress event, so we should be ignoring
every other event instead of canceling, as we are also ignoring the
multi-touch press events
Reviewed-by: woochan lee <wc0917.lee@samsung.com>
Differential Revision: https://phab.enlightenment.org/D11206
this is functionally wrong (the comparison fails) and also causes SIGBUS on
arm
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Reviewed-by: woochan lee <wc0917.lee@samsung.com>
Differential Revision: https://phab.enlightenment.org/D11198
this can be fetched using efl_provider_find from the recognizer
ref T8503
Reviewed-by: woochan lee <wc0917.lee@samsung.com>
Differential Revision: https://phab.enlightenment.org/D11177
this is a manager functionality, and recognizers are always child objects of
managers
ref T8503
Reviewed-by: woochan lee <wc0917.lee@samsung.com>
Differential Revision: https://phab.enlightenment.org/D11176
we still access this using private data in the in-tree recognizers, but
now it's also accessible normally to custom recognizers
ref T8503
Reviewed-by: woochan lee <wc0917.lee@samsung.com>
Differential Revision: https://phab.enlightenment.org/D11175
recognizers should be storing config values internally to avoid overhead
of multiple eo/hash lookups on every event
Reviewed-by: woochan lee <wc0917.lee@samsung.com>
Differential Revision: https://phab.enlightenment.org/D11174
we must write these recognizers using publicly available apis to ensure
that we don't accidentally start using private struct data
this requires a lot of changes to properly manage the config value for finger
size and update the recognizer data when changed (which external recognizers
will need to monitor an event to achieve) and then also to change some
recognizers so they don't use memset and unset the finger_size value
ref TT8503
Reviewed-by: woochan lee <wc0917.lee@samsung.com>
Differential Revision: https://phab.enlightenment.org/D11173
not sure why this was restricted to first touch point previously, but the logic
applies to all points as we don't want to be tracking input for a touch we
haven't gotten a down for
Reviewed-by: woochan lee <wc0917.lee@samsung.com>
Differential Revision: https://phab.enlightenment.org/D11169
since we retain touch info for the duration of a touch sequence, including
after a touch point has been unpressed, it's necessary to track the current
state of each point and then use that to accurately determine the number of
touches active
Reviewed-by: woochan lee <wc0917.lee@samsung.com>
Differential Revision: https://phab.enlightenment.org/D11168
canceling without a proper reset breaks the recognizer for successive events
Reviewed-by: woochan lee <wc0917.lee@samsung.com>
Differential Revision: https://phab.enlightenment.org/D11167
if we have one of these gestures where we are flicking/momentuming with multiple
touch points, we want to permit this so long as the touch points are moving vaguely
in the same direction, e.g., press -> swipe with 2 fingers
with this, we now cancel these gestures with multi-touch active if we detect motion
with subsequent touch events that doesn't match the vector of the "active" press
for which we are monitoring events
Reviewed-by: woochan lee <wc0917.lee@samsung.com>
Differential Revision: https://phab.enlightenment.org/D11165
this is useful in multiple places, no functional changes
Reviewed-by: woochan lee <wc0917.lee@samsung.com>
Differential Revision: https://phab.enlightenment.org/D11164
this rewrites the gesture event dispatcher to use a hash of hashes for
tracking which events are being watched on a given object to avoid:
* dispatching n gesture events per object to each callback, where n is the
number of gesture callbacks for any given type
* removing all gesture callbacks when only one callback is removed
this is not smart code. it should be improved at some time, but that time
is not now.
Differential Revision: https://phab.enlightenment.org/D11144
this allows us to provide the number of touch points active in any gesture
so we can detect e.g., double-tap with two fingers
Reviewed-by: woochan lee <wc0917.lee@samsung.com>
Differential Revision: https://phab.enlightenment.org/D11126
zoom requires two fingers for a pinch, so skip the first press
Reviewed-by: woochan lee <wc0917.lee@samsung.com>
Differential Revision: https://phab.enlightenment.org/D11088
if multiple fingers are pressed down, filter and use only the first finger
to make gesture recognizing more accurate
this may change later once tests develop
Reviewed-by: woochan lee <wc0917.lee@samsung.com>
Differential Revision: https://phab.enlightenment.org/D11087
any time multiple fingers are pressed down at the same time, we should
treat this as a single gesture like if only one finger was pressed
Reviewed-by: woochan lee <wc0917.lee@samsung.com>
Differential Revision: https://phab.enlightenment.org/D11086
this lets gesture framework track two touch points in order to distinguish between
successive presses and e.g., treat a simultaneous two finger tap as a single tap
gesture rather than two
it also simplifies some internal code and removes most hash lookups
Reviewed-by: woochan lee <wc0917.lee@samsung.com>
Differential Revision: https://phab.enlightenment.org/D11085
avoid having stale timer pointers around once timers have triggered
Reviewed-by: woochan lee <wc0917.lee@samsung.com>
Differential Revision: https://phab.enlightenment.org/D11081
some parts of this were entirely unreadable due to mixed tabs/spaces and other
bizarre formatting issues which somehow made it into the tree
Reviewed-by: Xavi Artigas <xavierartigas@yahoo.es>
Differential Revision: https://phab.enlightenment.org/D11053
for non-continuing gestures which have been canceled at this point, we must
not emit events in order to avoid sending useless events which serve no
purpose other than to waste cpu cycles
Reviewed-by: woochan lee <wc0917.lee@samsung.com>
Reviewed-by: Jaehyun Cho <jae_hyun.cho@samsung.com>
Differential Revision: https://phab.enlightenment.org/D11027
Summary:
Since the current Efl.Gesture.Events has canvas gesture events only,
Efl.Gesture.Events should be renamed to Efl.Canvas.Gesture_Events.
If other types of gesture events are newlly required later, which are
not based on canvas, then class Efl.XXX.Gesture_Events is required to
be introduced.
Reviewers: CHAN, segfaultxavi, bu5hm4n, zmike
Reviewed By: segfaultxavi
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11073
these were flattened to all be EFL_GESTURE_$MEMBER, which made them
impossible to read and use effectively
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D11026
The filter_event function calling a lot of times when it runs.
This can help performance by reducing the number of calls to the efl_data_scope_get() function.
Reviewed-by: Hermet Park <hermetpark@gmail.com>
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D10437
Summary:
The filter_event function calling a lot of times when it runs.
This can help performance by reducing the number of calls to the efl_data_scope_get() function.
Reviewers: Hermet, smohanty, bu5hm4n
Reviewed By: Hermet
Subscribers: zmike, bu5hm4n, q66, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D10437
Summary:
The internal and the API we would like is mostly a canvas API. A lot of the code
in evas is working around the fact that efl_input_device is not defined inside Evas.
This patch is the first step to try to clean this up.
Depends on D10487
Reviewers: zmike, raster, bu5hm4n, Hermet
Reviewed By: zmike
Subscribers: #reviewers, #committers
Tags: #efl
Maniphest Tasks: T8321
Differential Revision: https://phab.enlightenment.org/D10488
Summary:
D7762
Searching for event what is using in gesture manager.
But the value was wrong.
And now D10437 made it better.
Reviewers: Hermet, smohanty, zmike
Reviewed By: zmike
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D10438
division of integer by integer results integer.
this patch fix the case to make a division result more precise.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D10039
We need to keep in mind that the Manager and the Recognizers are not visible to the user.
The user only sees the events and the different Efl.Canvas.Gesture_* payloads.
Mike Blumenkrantz
Jaehyun Cho
Xavi Artigas
Woochanlee
Marcel Hollerbach
Cedric Bail
Daniel Kolesa
Wonki Kim
Hermet Park