If you need data, use a efl_future_then as done in every case here to get the same feature.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D7577
There is no point in having the object instancable. However, in order to
support bindings, we need to ensure that every abstract does have only
abstracts as inherit-parents, thus making this class abstract.
ref T7240
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D7599
This reverts commit 9b5155c9f1.
For now lets revert this, this breaks copy and paste, further more it
has the potential to break a lot more things, as eio_model tends to use
efl_loop_promise new, and then eina_promise_data_set, which is
explicitly forbidden.
This fixes crashing terminology instances.
I am not sure this is the right way to do it as binding would have to likely
to bind it manually.
Reviewed-by: Lauro Neto <Lauro Moura <lauromoura@expertisesolutions.com.br>>
Differential Revision: https://phab.enlightenment.org/D7492
This make all object that inherit from Efl.Loop_Consumer have an easy ability to create a future
from their link to a loop provider. This way there is no need to further lookup for a scheduler.
This can by applied after the patch series from T7471.
Reviewed-by: Xavi Artigas <xavierartigas@yahoo.es>
Differential Revision: https://phab.enlightenment.org/D7337
Xavi Artigas
Marcel Hollerbach
Cedric BAIL
Cedric BAIL
Carsten Haitzler
Andy Williams