On Fri, Dec 2, 2016 at 2:58 AM, Carsten Haitzler <ras...@rasterman.com> wrote: > 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...
Yes, I do agree with fixing it for once and for all, as you said these cases will happen... and we must handle them. What I tried to say is that our performance impact should be minimal on the usual case, optimize for that. Marcel's solution seems to do it nicely (in text, I did not check the patch). -- Gustavo Sverzut Barbieri -------------------------------------- Mobile: +55 (16) 99354-9890 ------------------------------------------------------------------------------ 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
