On Tue, Sep 13, 2016 at 6:59 AM, Gustavo Sverzut Barbieri <barbi...@gmail.com> wrote: > On Tue, Sep 13, 2016 at 10:43 AM, Felipe Magno de Almeida > <felipe.m.alme...@gmail.com> wrote: >> On Sep 13, 2016 5:49 AM, <marcel-hollerb...@t-online.de> wrote: >>> >> >> [snip] >> >>> There could be a helper method which does the "fetch the loop and create >>> the job" stuff. >>> >>> But with the feature of multiple efl loops in one process you have to >>> decide on which loop to run the timer, i dont really see how you can get >>> arround deciding that ... >> >> If we lived without one for so long we probably can have a default one. > > not just that, but maybe all loop-users could provide loop functions > themselves, so if I have a elm_window or an efl_net/efl_io that uses > the loop I could do o.timer_add(seconds) -> timer_obj, it would do > the loop_get + efl_add() + set interval. > > same for job, etc.
I have been wondering if we couldn't have a new class of object. Interface "provider", that would get their function resolved using efl_provider_find internally instead of the class hierarchy. This would solve what we are talking right now and simplify things a lot I think. Arguably, I don't know of any language that do provide this feature... > also, why job is a promise while timer is not? this is confusing, > should offer timer/idle_enter/idle_exiter/idler as a promise as well, > no? timeout is ;-) I agree we should provide idler and friends also as a promise. Make a lot of sense for the one time off usage that we have all over the place. -- Cedric BAIL ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
