On 17/06/16 09:33, Jean-Philippe André wrote: > On 17 June 2016 at 17:21, Tom Hacohen <t...@osg.samsung.com> wrote: > >> On 17/06/16 03:21, Carsten Haitzler wrote: >>> On Thu, 16 Jun 2016 19:29:52 +0100 Tom Hacohen <t...@osg.samsung.com> >> said: >>> >>>> On 16/06/16 10:47, Carsten Haitzler wrote: >>>>> On Thu, 16 Jun 2016 14:28:22 +0900 Jean-Philippe André < >> j...@videolan.org> >>>>> said: >>>>> >>>>> >>>>>>>> The ON_HOLD flag, now called efl_event_processed_get/set() is a >> better >>>>>>>> approach to stop processing events. >>>>>>> >>>>>>> That is off topic, but seriously something we should consider asap if >>>>>>> we want to drop the return type of event. I have not any case in mind >>>>>>> where returning EINA_FALSE make sense. Should we drop it ? >>>>>>> >>>>>> >>>>>> I am also thinking we should drop it. >>>>>> Pretty sure the few places that return EINA_FALSE right now are >> actually >>>>>> mistakes and sources of bugs. >>>>> >>>>> i think so too. drop the return. >>>>> >>>> >>>> The return is mega useful, though I'm open to implementing it >>>> differently. The return is there so you can filter events. We currently >>>> have things like "on_hold" in input events to mark an event has been >>>> processed and should stop propagating, but the return lets you stop the >>>> callback. I guess we can change it to be "eo_event_callback_stop(obj)". >>> >>> but the thing is.. we don't want to stop the callback. well not where >> hold is >>> used. you want to still get the cb but put on hold any actions.like >> calling the >>> clicked callback. you still need the event to get the matching mouse up >> fro the >>> mouse down for example, but since you started a drag, after n move >> events the >>> mouse up (and future moves) should not be acted on. >> >>>> Btw, it shouldn't be a bool, there are defines for the return values. I >>>> should have typedeffed the type. I'm open to changing to >>>> eo_event_callback_stop though, just let me know. >>>> >>>> Grep for EO_EVENT_STOP, it is already used by code, even code I didn't >>>> write. :) >>> >>> see above. the only use case we have to date is the above and a return >> just >>> doesn't do it. you need to have a modified event go through afterwards. >>> >>> i did the return true/false for ecore events for pass through. over the >> years i >>> have recognized this as a mistake. it's more pain than gain. >> >> Again, I don't mind changing it to eo_event_callback_stop(obj). Feels >> better for making event propagation to stop, but I do like being able to >> stop it. It is used in the EFL, I just got the name wrong, >> EO_CALLBACK_STOP. :) >> It's useful for text filtering iirc, to make it stop processing the >> filter if one has already failed. It is used and useful. >> >> > obj here would then be the Eo_Event's object? > As Cedric noted, this is not like ON_HOLD (actually called "processed"), > because we call that on the event->info. > > I agree stop can be useful sometimes, but only quite rarely (in practice, > in our code). >
That's why I suggested maybe making it an external call. The only problem with that is that it'll have to be the absolute last call in the callback, otherwise it could confuse Eo and generate bugs. I could make it more safe by making people adding the event type to the stop function, but that's still not airtight. -- Tom. ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://sdm.link/zohomanageengine _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
