On Thu, 1 Dec 2016 12:36:28 -0200 Gustavo Sverzut Barbieri <barbi...@gmail.com> said:
> On Thu, Dec 1, 2016 at 6:33 AM, Carsten Haitzler <ras...@rasterman.com> wrote: > > On Wed, 30 Nov 2016 21:58:19 -0800 Cedric BAIL <cedric.b...@free.fr> said: > > > >> Hello, > >> > >> So we have currently a bug showing up for some people, that is > >> actually related to how we handle event when a callback is registered > >> from within a call triggered by that same event. There is a few > >> possible behavior : > >> > >> - Do not call the callback until the next time the event is triggered. > >> - If inserted before the currently executed callback, do not call, if > >> after do trigger the call. > >> - Trigger the call whatever the position of insertion (maybe even > >> trigger it right away if it was inserted before) > >> > >> I am leaning toward the first case, but I am not really sure this is a > >> good idea in all case. Any one with a good reason why we should do any > >> of the other possibility ? > > > > hmm. i think it's more complex than this. so some pseudocode: > > > > -> event_call(obj, ev1) > > ---> event_cb_add(obj, ev1) > > > > so what to do here? when the event cb is added to the > > end of the array should it be called again while event_call() is still > > calling.. in this case i'd say it shouldn't. > > > > now here comes the complex stuff: > > > > -> event_call(obj, ev1) > > ---> event_cb_add(obj, ev1) > > ---> event_call(obj, ev1) > > > > so now what? inside the 2nd event_call should we call the callback we just > > added before? yes. i'd say so... now combine with the 1st case above. .. > > what happens when we go back and return to the FIRST event_call. we called > > in the child event_call()... should we call in the parent? hmmmm.... i'd > > say no. > > > > how do we make this work AND make it efficient? but the above 2 cases are > > pretty much a core concept that would expand to all other cases up and down > > the stack. i agree that once you add an event that future event callback > > calls should trigger it... but only future event callback calls that are > > STARTED after the event cb add. not existing ones that are still "being > > processed". > > agreed this is the expected behavior, however pretty uncommon in real > life scenario to emit the event from the event callback of the same > object, after all if done naively this can trigger infinite recursion. even if uncommon... it's still something we have to handle. in fact this can happen as side-effects. like: on mouse enter... move object move of object indirectly causes a mouse out e.g. it shows an object on top mouse out handler raises original object original object now gets a mouse in... ... repeat :) or things like this happen where feedback loops happen. often these feedback lops are shortcut somehow and don't recurse forever it is does mean that you can have a mouse in called on an obj inside the mouse in and if you add/remove mouse in callbacks this can all be affected. either way we need a simple and consistent behaviour that works the same way all the time AND is "logical" and "makes sense". what this is about is... what makes sense? above is what i proposed makes sense to me... it seems to make sense to you. what about others... -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel