While Eina_Coro provides a solid base, to use the main loop to
schedule coroutines it needs some manual work we want to avoid.
Efl.Loop.coro method will take a function and schedule it using the
given priority, the returned value is then resolved in a promise for
the returned future.
Basically all users must do is write a function that looks like a
synchronous code and calls eina_coro_yield() (or helper macros), that
will go back to the main loop and then it will reschedule the
coroutine to run according to its priority.
This should reduce the number of callbacks in user's code.
The internal logic should be improved further in the future to synchronize itself
with loop wake up whenever possible (Especially true for the high frequency poller).
The original idea behind knowing the app's version of EFL is not
a great story. It comes from the fact that some bugs exist in
earlier versions of EFL, and some things need to be fixed. But
those fixes may break behaviour for older apps. This patch is
opening the way to the slippery slope of bug compatibility.
Unfortunately this is a requirement if we want to be able to move
forward and not break apps when we fix bugs (behaviour or ABI).
I hope we will not need to implement too many (if any) workaround
such issues. For now, this will only be used as debugging info.
EFL_MAIN() and ELM_MAIN() will both set the app's EFL version
automatically at startup time. Some internal helpers can be added
later to check how the app build-time and run-time version of
EFL differ.
@feature
Note: this is both @class and @property. Hope that's ok for
all bindings.
This returns same as ecore_main_loop_get() (which now uses the eo
api instead).
Ping @cedric (so he can check this patch).
This lets me narrow down the remaining cases of pointers across the EFL.
The void pointers will later need to be reevaluated on per-case basis and
replaced appropriately where possible/feasible.
this is an args event. right now we don't use it, but this should be
done by some of the setup/init of an app and then produce an args
event. the idea would be that this can be used by single-instance apps
like web browsers, terminology to treat launch as an event.
Complex types (i.e. list, array, hash, accessor etc.) now do not require
pointers with them anymore (the pointer is implied) and the same goes for
class handles. Eolian now explicitly disallows creating pointers to these
as well. This is the first part of the work to remove pointers from Eolian
completely, with the goal of simplifying the DSL (higher level) and therefore
making it easier for bindings (as well as easier API usage).
@feature
Summary:
object_find is more generic, so other mechanisms can also reuse the
code.
The object itself has to support the function, so there is no need for
eo_isa which would have a negative performance impact.
The base class implementation calls interface_get on the parent, so a
override of the function can just call the super function to continue in
the recursion.
Test Plan: just run the eo test suite
Reviewers: raster, tasn, jpeg
Reviewed By: tasn, jpeg
Subscribers: felipealmeida, netstar, cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D3909
this means that on loop_get on any obj as long as its a child of a
loop obj... it'll retunr that loop now. it will work. no more code
needed.
we can shortcut this with ui/gfx objects returning the mainloop
singletone.
Gustavo Sverzut Barbieri
Guilherme Iscaro
Cedric BAIL
Stefan Schmidt
Daniel Kolesa
Tom Hacohen
Jean-Philippe Andre
Carsten Haitzler
Marcel Hollerbach