The init/shutdown handling for efl libraries was a bit sloppy and
unbalanced in the exactness binaries. Switching over to use
ecore_eas_init/shutdown here instead of doing all libs individually.
Differential Revision: https://phab.enlightenment.org/D11289
This has been in place during development and not updated for recent
changes and merge into efl master.
Differential Revision: https://phab.enlightenment.org/D11287
Given a better overview after the wall of text we are seeing from
starting and stopping jobs in parallel.
Differential Revision: https://phab.enlightenment.org/D11286
Exactness has been developed in a separate git repo for many years. This
finally moves it over into efl. Having it in tree allows us for easier
testing with our current main target elementary_test and integration
into our CI system (patches for this are work in progress already).
We are only importing the lib and binary for test execution, not the
full set of test data. This is would be over 500MB and thus it will stay
in a different repo and only made available during the actual testing.
[The original patch was made by Daniel Zaoui. Over the course of review
and testing it got extended with build fixes for API changes and mingw
compilation support from Stefan Schmidt and Michael Blumenkrantz]
Differential Revision: https://phab.enlightenment.org/D11285
For our exactness testing we are dlopen() the elementary_test
executable. Until glibc 2.30 this was posible with -pie, but it changed
in the glibc version. They no longer allow these executables to be
dlopen()'ed.
As a workaround for now we are building elementary_test also as a shared
object file which we load and use in the exactness testing process.
The code came from Marcel Hollerbach and I only tested it and fixed up a
small detail.
Differential Revision: https://phab.enlightenment.org/D11284
To keep backward compatibility on size calculation, elm_index implements
group_calculate and the size calculation in the removed sizing_eval is
added to the implemented group_calculate in elm_index.
This was properly applied to all cases except this one where it
was overlooked/forgotten. That resulted in the @c_name() feature
with enums being broken because of bad memory.
Fixes T8596.
Summary:
Update the test to check that the first character is rendered after the obstacle.
To ensure that the obstacle feature keeps working correctly.
Reviewers: ali.alzyod, woohyun
Reviewed By: ali.alzyod
Subscribers: segfaultxavi, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11033
This causes many issues because textbox functions deals with <br> <tab> differently depending that user write them with or without '/' at the end (for example <br> vs <br/>)
while most functionaliity are the same (like viewing <br> and <br/> are the same).
cursor dealing with these tags can be differently.
now we will assume <br> <tab> are already have there own closing tag, even if it is missing
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D11293
Story:
This revision got landed twice, I do not know what happend, but when i
wanted to land that initially with git phab, something reseted the state
of this revision to the initial version, and also changed the
authorship. This time, this commit contains all changes, and the correct
authorship, sorry for the noise.
Summary:
Add @since tags at stable (not tagged with @beta) `.eo` c#/c++ tests. Doing so,
eolian_enforce_since shouldn't accuse at stable tests.
Depends on D11264
Resolves T8600
Reviewers: zmike, segfaultxavi, woohyun, bu5hm4n
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Maniphest Tasks: T8600
Differential Revision: https://phab.enlightenment.org/D11265
this is actaully usefull ... for people not forgetting things.
Reviewed-by: Xavi Artigas <xavierartigas@yahoo.es>
Reviewed-by: Daniel Kolesa <daniel@octaforge.org>
Differential Revision: https://phab.enlightenment.org/D11266
these two objects have zero relation, and I don't know why this ever
existed
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D11243
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
efl explodes when this assert fails and presents bizarre errors which
obscure the actual test failure, so add a more explicit message as a
reminder to check this instead of trying to dive into insanity
Differential Revision: https://phab.enlightenment.org/D11238
adds a very small implementation of a custom recognizer, registers it,
verifies events are processing as they should, then removes it
Differential Revision: https://phab.enlightenment.org/D11224
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
a touch press is both a touch and a move event, which means the canvas must
update its list of target objects on the first touch press to avoid using the
wrong objects when processing events
@fix
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D11163
Stefan Schmidt
Daniel Zaoui
Jaehyun Cho
Daniel Kolesa
abdulleh Ghujeh
Marcel Hollerbach
Xavi Artigas
Ali Alzyod
Lucas Cavalcante de Sousa
Mike Blumenkrantz