Summary:
this is not a valid event type to add a handler for, it indicates an
uninitialized event which means the component is not active and everything
will break
@fix
Depends on D9255
Reviewers: bu5hm4n
Reviewed By: bu5hm4n
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9256
Summary:
this should not be a silent return since event handlers are depended upon
so heavily
Depends on D9254
Reviewers: bu5hm4n
Reviewed By: bu5hm4n
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9255
it appears that this could be emulated with other functions. Plus the
function had the limitation, that no constructors could be used.
ref T7597
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D7985
Until this commit eo did class functions as part of the vtable, which
enabled those functions to be overwritten in classes inheriting another
class. However in task T7675 we decided that this is not really good for
bindings, as most OOP languages do not support this sort of feature.
After this commit eolian realizes class function completly outside of
the vtable, the c-symbol that is the class funciton is now just directly
redirecting to a implementation, without the involvement of the vtable.
This also means a change to the syntax created by eo:
Calling before:
class_function(CLASS_A);
Calling after:
class_function();
Implementation before:
class_function(const Eo *obj, void *pd) { ... }
Implementation after:
class_function(void) { ... }
This fixes T7675.
Co-authored-by: lauromauro <lauromoura@expertisesolutions.com.br>
Reviewed-by: Daniel Kolesa <daniel@octaforge.org>
Differential Revision: https://phab.enlightenment.org/D7901
event handler start at 1 (see _ecore_event_message_handler_type_new and
_ecore_event_message_handler_efl_object_constructor) so that handlers[0] is not
allocated. this patch avoid invalid memory access.
this fixes T7349
Differential Revision: https://phab.enlightenment.org/D6966
Summary:
Ecore internally uses 10 events, from ECORE_EVENT_SIGNAL_USER=1 to
ECORE_EVENT_SYSTEM_TIMEDATE_CHANGED=10. The Ecore.Event.Message_Handler
singleton that holds the counter of events is initialized with -1.
This is followed in _ecore_event_init() by ten calls to
ecore_event_message_handler_type_new(), which increase the counter of
event by one each.
This results in an event counter to be 9 (-1 + 10) at the end of the
initialization of ecore_events. This means that the next event to be
created will have a value of 10, which will overlap with
ECORE_EVENT_SYSTEM_TIMEDATE_CHANGED. As such, these two distinct events
will be aliased and their associated handlers will be called at
unexpected times, with unexpected data.
By changing the constructor value from -1 to 0, we prevent this event
aliasing.
Fixes T6605
Reviewers: zmike, Hermet
Reviewed By: Hermet
Subscribers: cedric, #reviewers, #committers, zmike
Tags: #efl
Maniphest Tasks: T6605
Differential Revision: https://phab.enlightenment.org/D6894
stealing the message data here prevents events which aren't being flushed from
ever being usable again and is unnecessary since the free callback will be
automatically called during the destructor
ref 5dd52fd09b
we really should have data inside the loop object, so begin moving it
one small thing at a time. this is the basics that will allow multiple
efl loops. make an eo efl object and class for fd handlers that is efl loop
bound make fd handlers really bound to their parent loop and not global as
well as have a nice class/obj. create an message queue per loop and
put legacy ecore events on top of it... and a lot more.
this is not 100% done, but it's a lot of the core and groundwork.
various ecore_timer_add(), ecore_diler_add() etc. need changes.
The following still need doing:
ecore_timer (internal usage for sure)
ecore_idler (internal usage for sure)
ecore_idle_enterer
ecore_idle_exiter
ecore_pollers? (is the new efl loop stuff ok?)
ecore_exe (fork/spawn from any thread and track exe from that thread?)
ecore_signal code
ecore_throttle (should we have a single global too? we have per loop)
ecore_app ? (should every loop be given its own argv/argc?)
Lots of internal ecore code uses/calls these legacy calls and we
should have efl loop replacements and/or use the ones we have
The following will bedifferently designed for loop to loop
control/messaging/ipc:
ecore_thread
ecore_pipe
Mike Blumenkrantz
Marcel Hollerbach
Shinwoo Kim
Yeongjong Lee
Jean Guyomarc'h
Mike Blumenkrantz
Jean-Philippe Andre
Carsten Haitzler