On Tue, 19 Apr 2016 15:10:59 +0100 Tom Hacohen <t...@osg.samsung.com> said:
> On 19/04/16 06:52, Carsten Haitzler wrote: > > On Mon, 18 Apr 2016 14:18:06 +0100 Tom Hacohen <t...@osg.samsung.com> said: > > > >> On 12/04/16 12:36, Carsten Haitzler wrote: > >>> On Tue, 12 Apr 2016 12:27:02 +0100 Tom Hacohen <t...@osg.samsung.com> > >>> said: > >>> > >>>> On 12/04/16 10:57, Carsten Haitzler wrote: > >>>>> just realized... Eo_Event *.... > >>>>> > >>>>> it has obj. shouldn't it ALSO have src too? for event propagation we > >>>>> really want to maintain src to be the original object the event happened > >>>>> on AND obj to be the event the callback is being called on... > >>>>> > >>>>> ... comments? > >>>>> > >>>>> > >>>> > >>>> Let me start by saying that the magic of the Eo_Event structure is that > >>>> we can add to it when we need to. Like now. :) > >>> > >>> yeah - i know. but let's add to it now... :) > >>> > >>>> At the moment we just overwrite obj (as you may know) and send a > >>>> "native" event. The problem I have with src is that I feel like it's > >>>> exposing internals of widgets for no apparent benefit. Having src feels > >>>> useful to me as well, but I don't have a usecase in mind. > >>> > >>> you can't otherwise know where the event really originated. you only know > >>> you got it. if it propagated... there would be cases you want to know - if > >>> you are the original src of the event or just got a propagation - > >>> otherwise it could be handled multiple times like > >>> > >>> if (event->src != event->obj) // propagated event > >> > >> I understand how it can be used, what I don't know is the purpose. A > >> purpose like: "you can check if it's a propagated event" is not a real > >> purpose, it's a method. Why would you want to know if it's a propagated > >> event? What's the real use case where knowing that is useful? > >> > >>> > >>>> In cases where it's really needed, src could be added to the event info. > >>> > >>> i think that's really too special/manual. i think it likely should be a > >>> core feature. right now we have event forwarders ... and here src would > >>> need to change. currently that's gore. i think we should also add > >>> propagation to parent too like evas already does. that would necessitate > >>> this feature in core. we currently dont have a propagate flag. in fact > >>> you likely want to propagate some events and not others. > >>> > >>> anyway - i remember int he past doing code and going "shit. i dont know > >>> where the event came from. i can't fix this simply. i have to do some > >>> weird stuff instead". i remember making a mental note to fix this in > >>> future. :) i'm now voicing that note. :) > >> > >> I'm not strictly against, just lacking an example... Got one you can > >> describe? > > > > i have an example. del events. let's say a del event propagated. the obj > > now is not the object deleted but the object the cb was called on. you > > REALLY want to know the src (the deleted object) so you can do things like > > remove the daat you had attached or references to it etc. etc. > > Events are forwarded explicitly exactly because of that. You don't want > to forward all of the events. Moreover, you just explained exactly why > you'd never want to do that, because it'll be a mess. If you forward > everything like you imply here, you'll have to do the "if src != obj" in > every callabck, that's unacceptable. > > So this is not a good example at all. i was giving an example of a propagated (or forwarded) event where you REALLY need to know the difference between that specific object and the source of the event. if someone propagated del events - then you'd NEED to know. > > that brings me to propagation. we currently have event forwarders. these > > don't handle "forward to parent regardless what parent is". so either we > > need propagation methods like the forwarder add/del OR use target obj == > > NULL to mean parent. (or something similar - have a magic special object > > created as a global to be parent and use that obj as a special marker). > > I disagree with the "propagation all the way thing", so I don't see this > as a good example either. propagation all the way? eh? we have propagation (to parent) in evas already. it's heavily used. it propagates INPUT events. it's just a boolean. that alone is all the reason we need to have propagation at all. but as eo doesn't know (or care) about if an event is propagatable or not, it needs to be explicit as to which ones are or are not. and thus you have to be able to explicitly say which events should propagate or not. another alternative is we extend events to have a "can propagate" flag and any event marked as such will propagate if propagation is enabled. it is more usable. :) > > > >>> > >>>> -- > >>>> Tom. > >>>> > >>>> ------------------------------------------------------------------------------ > >>>> Find and fix application performance issues faster with Applications > >>>> Manager Applications Manager provides deep performance insights into > >>>> multiple tiers of your business applications. It resolves application > >>>> problems quickly and reduces your MTTR. Get your free trial! > >>>> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z > >>>> _______________________________________________ > >>>> enlightenment-devel mailing list > >>>> enlightenment-devel@lists.sourceforge.net > >>>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > >>>> > >>> > >>> > >> > > > > > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
