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). -- Jean-Philippe André ------------------------------------------------------------------------------ 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
