this is done inorder to ensure that noone ever thinks of creating theire
own app/loop object.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D7982
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
I forgot to spin the sub-loop, so this was previously just a test to verify
that the IDLE callback was working.
now this spins the sub-loop on the idle callback and tests the idle enter
callback to verify that the main loop is being iterated
Reviewed-by: Derek Foreman <derekf@osg.samsung.com>
Differential Revision: https://phab.enlightenment.org/D7874
having multiple loops which interact is a valid use case that should be
tested to ensure functionality
Reviewed-by: Derek Foreman <derekf@osg.samsung.com>
Differential Revision: https://phab.enlightenment.org/D7868
This brings in the possibility to receive the app object from bindings.
With the app object you can listen to pause / args / terminate / resume
events.
fix T7509
Differential Revision: https://phab.enlightenment.org/D7480
Marcel Hollerbach
Mike Blumenkrantz
Cedric BAIL
Mike Blumenkrantz