Summary:
when someone accidently does not clean up all his animation callbacks,
we might end up with a lot of errors on console, as we keep delivering
tick events to a dead object.
Reviewers: zmike, cedric, segfaultxavi
Reviewed By: zmike
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D10998
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:
we know these ahead of time since they're hardcoded, so we can block their
emission just like we do for eo events
ref T8321
Depends on D10354
Reviewers: cedric
Reviewed By: cedric
Subscribers: bu5hm4n, cedric, #reviewers, #committers
Tags: #efl
Maniphest Tasks: T8321
Differential Revision: https://phab.enlightenment.org/D10355
Summary:
these are not strictly related to the event callback types and should not
have their emission tied to the corresponding event
also add unit test to verify all of these
@fix
Reviewers: cedric
Reviewed By: cedric
Subscribers: bu5hm4n, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D10353
Summary:
evas_object_callbacks_finalized could take NULL obj because
_efl_canvas_object_efl_object_finalize could call it with NULL obj.
Reviewers: bu5hm4n, jsuya, Hermet
Reviewed By: bu5hm4n
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D10141
Summary:
this reduces the necessary event subscriptions for cases where someone
is likely to want to listen on these events
ref T7875
Depends on D9996
Subscribers: cedric, #reviewers, #committers
Tags: #efl_api
Maniphest Tasks: T7875
Differential Revision: https://phab.enlightenment.org/D9997
the problem here is that we might subscribe to an event before
evas_object_callbacks_init has happened. This sounds like something
which might not happen. However, with the interfaces project this
definitly will start to happen because someone will some day overwrite
the evas object and do something before the constructor, which will not
raise a error or something but will simply just not work.
With this commit we are not listening to the event callbacks via event
emission but rather via inheritance. With this there is no "earlier than
we listend" point, and the issue in the task is solved by itself.
fix T8202
Reviewed-by: Jaehyun Cho <jae_hyun.cho@samsung.com>
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9841
Summary:
https://phab.enlightenment.org/T7544
Provides a way for a user to get a gesture manager, recognizer instance.
Supports different recognizer properties for each target(Eo).
Gesture, Touch Class Life-cycle re-implementation. for supporting multiple touches.
Add below gestures.
efl_canvas_gesture_tap
efl_canvas_gesture_double_tap
efl_canvas_gesture_triple_tap
efl_canvas_gesture_long_tap
efl_canvas_gesture_momentum
efl_canvas_gesture_zoom
efl_canvas_gesture_flick
Test Plan:
Simple test -> test_gesture_framework.c
More test cases will upload.
Reviewers: woohyun, smohanty, segfaultxavi, Jaehyun_Cho
Reviewed By: Jaehyun_Cho
Subscribers: Jaehyun_Cho, segfaultxavi, cedric
Tags: #efl, #do_not_merge
Differential Revision: https://phab.enlightenment.org/D7579
Summary:
When I add "efl_event_callback_add(btn, EFL_GFX_ENTITY_EVENT_VISIBILITY_CHANGED, _cb, NULL)",
_cb is not called. Because of callback_mask is not set correctly.
Test Plan: unit test
Reviewers: zmike, cedric
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8528
Summary:
This event can just be renamed, no need to handle legacy. The reason for
this, that this event is used to map to EVAS_CALLBACK_ enum fields,
which means, the legacy names of the event does not matter.
ref T7476
Reviewers: cedric, segfaultxavi, zmike, stefan_schmidt
Reviewed By: zmike
Subscribers: #reviewers, #committers
Tags: #efl
Maniphest Tasks: T7476
Differential Revision: https://phab.enlightenment.org/D8242
Summary:
this requires some internal hackery to preserve legacy compatibility
and correctly translate the single new event into two legacy events
ref T7558
Depends on D8018
Reviewers: segfaultxavi, bu5hm4n
Reviewed By: segfaultxavi
Subscribers: bu5hm4n, segfaultxavi, cedric, #reviewers, #committers
Tags: #efl_api
Maniphest Tasks: T7558
Differential Revision: https://phab.enlightenment.org/D8019
Summary:
this makes it more obvious which events are legacy and makes them easier to remove
in the future
Reviewers: bu5hm4n
Reviewed By: bu5hm4n
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8002
slight tweak to make this more consistent with meaning and docs
ref T7560
Reviewed-by: Marcel Hollerbach <marcel-hollerbach@t-online.de>
Differential Revision: https://phab.enlightenment.org/D7988
the convention for event naming is to use $property,changed where possible
and to always emit related data with the event to reduce function calls
ref T7558
Reviewed-by: Marcel Hollerbach <marcel-hollerbach@t-online.de>
Differential Revision: https://phab.enlightenment.org/D7987
Summary:
this interface only contains a single event which is implemented only by the
canvas object
ref T7561
Reviewers: cedric, segfaultxavi
Reviewed By: segfaultxavi
Subscribers: #reviewers, #committers
Tags: #efl
Maniphest Tasks: T7561
Differential Revision: https://phab.enlightenment.org/D7905
Summary:
Eolian adds a per-class BETA guard (like EFL_UI_WIN_BETA) to any method tagged
as @beta. This means that any app (and the EFL code) wanting to use BETA features
has to enable them class by class, which is cumbersome.
This commit replaces the individual guards with the global EFL_BETA_API_SUPPORT
guard, so apps only need to define one symbol to access BETA features.
Any usage of the per-class guards has been removed from the EFL code and examples.
When building EFL the global guard is defined by configure, so all EFL methods
already have access to BETA API.
Efl_Core.h and Efl_Ui.h no longer define EFL_BETA_API_SUPPORT. Apps wanting to
use BETA API have to define this symbol before including any EFL header
(It has been added to the examples requiring it).
Test Plan:
make && make check && make examples still work, but there's a lot less #defines
in the code
Reviewers: zmike, bu5hm4n, q66
Reviewed By: q66
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Maniphest Tasks: T6788
Differential Revision: https://phab.enlightenment.org/D7924
Gesture manager doesn't care about focus manager events, animation events,
and various other things it's currently hooking.
We can save a lot of pointer indirection nonsense by only paying attention
to events it can actually do something with.
Differential Revision: https://phab.enlightenment.org/D7764
Signed-off-by: Derek Foreman <derek.foreman.samsung@gmail.com>
We frequently process an array of several events at once, so we can now
look up the gesture manager private data once for the entire array.
Differential Revision: https://phab.enlightenment.org/D7763
Signed-off-by: Derek Foreman <derek.foreman.samsung@gmail.com>
it does not really matter if a obj is NULL or not when deleting a callback.
The result might be NULL anyways when the callback is not found.
Additionally, this is very verbose, and leads to the fact that most of
the time normal calls to evas_object_event_callback_del* should be if
(!obj) evas_object_event_callback_del* which is annoying and wastefull.
Differential Revision: https://phab.enlightenment.org/D7028
Summary:
To take screenshots, Enlightenment makes a new snapshot object, performs
a manual render, and uses the snapshot results.
Turns out if this happens while an async render is in progress, the
async render's completion triggers a render post callback on the snapshot
object even though it's never been involved in a render.
We need to defer new render post callbacks until any currently running
render completes, then add them during that render's post.
Fix T7156
Reviewers: devilhorns, zmike
Reviewed By: devilhorns, zmike
Subscribers: devilhorns, cedric, #committers, zmike
Tags: #efl
Maniphest Tasks: T7156
Differential Revision: https://phab.enlightenment.org/D6711
Summary:
this should only happen if the user has made a mistake regarding the
existence or type of an object, so ensure that an error message occurs to
help debug any failures which result
fix T6326
Reviewers: bu5hm4n, Hermet, woohyun, devilhorns
Reviewed By: Hermet
Subscribers: cedric, #committers
Tags: #efl
Maniphest Tasks: T6326
Differential Revision: https://phab.enlightenment.org/D6322
so the MAIN loop is actually an efl.app object. which inherits from
efl.loop. the idea is that other loops in threads will not be efl.app
objects. thread on the creator side return an efl.thread object.
inside the thread, like the mainloop, there is now an efl.appthread
object that is for all non-main-loop threads.
every thread (main loop or child) when it spawns a thread is the
parent. there are i/o pipes from parnet to child and back. so parents
are generally expected to, if they want to talk to child thread, so
use the efl.io interfaces on efl.thread, and the main loop's elf.app
class allows you to talk to stdio back to the parent process like the
efl.appthread does the same using the efl.io interfaces to talk to its
parent app or appthread. it's symmetrical
no tests here - sure. i have been holding off on tests until things
settle. that's why i haven't done them yet. those will come back in a
subsequent commit
for really quick examples on using this see:
https://phab.enlightenment.org/F2983118https://phab.enlightenment.org/F2983142
they are just my test code for this.
Please see this design document:
https://phab.enlightenment.org/w/efl-loops-threads/
So, this is maybe not the best fix. The question is should we be able to
get efl_data_scope_safe_get return the object private data, when we are
currently executing the object EFL_EVENT_DEL callbacks. Right now we don't
and this lead to bug where we wouldn't have been able to destroy a callback
and get that callback triggered later on destroyed data (I had a crash in
terminology). I have switched back to the not _safe_ version which doesn't
enforce this, but that might not be the only place that need a fix.
this fixes a bit wraparound in the shift as the 1 is an int (32bit)
type that then gets shifted .. then after that cast to 64bit.
found by PVS studio
@fix
Eina_Clist can actually change the pointer in the cell next bypassing
the CoW infrastructure leading to trouble. Considering the case here,
using the optimization of Eina_Clist is not necessary and if performance
issue arise, can be fixed by using a dichotomic search when removing
data. I don't think it is necessary to add this complexity without
a real life case.
This reverts commit f69686ba40.
this causes major crashes in e every time you move and resize a
window. i cant even debug it properly because i cant move or resize
windows to get terminals up to debug it... this is bad... so until a
fix is found better to go back to working...
adding an "event rect" is a common use case for rectangles, but I needed
a smarter event rect so I sent one off to school and it came back like this.
an event_grabber is a smart object which functions like a normal event rect
which has color(0,0,0,0), but with an important difference: it can have smart
members. event propagation works differently for an event_grabber:
normal:
event -> layer -> smart(obj1,obj2,obj3) ->(?) other objects
in this case, obj1,obj2,obj3 are all "inside" the smart object and their stacking
will always be considered as being inside the smart object. rendering is also
tied to the smart object in this case, as is clipping.
an event which reaches a smart object will be sent to the objects inside,
and then may continue through the smart object if there are no objects which
block repeating.
event_grabber:
event -> layer -> event_grabber -> obj1,obj2,obj3 -> STOP
in this case, obj1,obj2,obj3 are unmodified after being added to the event_grabber
and can be stacked, rendered, and clipped completely independently of the
event_grabber.
the event_grabber is considered an "event_parent" for this case. member objects
are not "inside" the event_grabber, and they are unable to receive events on
their own. instead, the event_grabber, which must be stacked above all its
members, receives events and propagates them top->down through its member objects.
if none of the member objects block the repeat of an event then the event will
still be blocked from further propagation past the event_grabber.
object lifetimes are independent of the event_grabber; deleting the event_grabber
has no effect on its members.
@feature
Since ecore now uses efl events to feed input events to the
canvas, anyone can now listen to any event on the evas. But
when using the legacy API the event info needs to be the legacy
struct, and not the eo event info otherwise crashes will happen.
While this is a new use of events, I consider it valid and it's
better to fix it rather than disallowing it. Fixed by wrapping
evas events the same way evas object events were handled.
Fixes T5266