On Thu, 1 Dec 2016 12:36:28 -0200 Gustavo Sverzut Barbieri <barbi...@gmail.com>
said:
Advertising
> 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
