On 21/04/16 13:18, Stephen Houston wrote:
> The obj is the widget, Genlist for instance, and the event_src is which of
> the object_items caused the events. Useful for the MVC style widgets, no?
For those cases you want it in the event_info. It's very specific and
the origin can be a handle, an eo object, an index and whatnot...
--
Tom.
> On Apr 21, 2016 4:23 AM, "Tom Hacohen" <t...@osg.samsung.com> wrote:
>
> On 21/04/16 05:02, Hermet Park wrote:
>> And Im not sure its necessity and still wonder any actual scenarios
>> for it. As far as i remeber, it was introduced for ephysics but I
>> have no idea where event_src is actually being used now.
>>
>> We could add source event when it really needs?
>
> For whatever it's worth, we also have event_src in elm_widget events,
> and there it's also useless for all I know.
>
> This is what I'm saying, let's add when needed, or at least when we
> think it's needed. We are not in either place.
>
> --
> Tom.
>
>
>>
>> -----Original Message----- From: "Carsten
>> Haitzler"<ras...@rasterman.com> To: "Tom
>> Hacohen"<t...@osg.samsung.com>; Cc: "Enlightenment developer
>> list"<enlightenment-devel@lists.sourceforge.net>; Sent: 2016-04-21
>> (목) 10:43:08 Subject: Re: [E-devel] RFC: eo events.... add Eo *src ?
>>
>> 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?
>>
>> another example:
>>
>> struct _Evas_Event_Mouse_Down /** Mouse button press event */ { int
>> button; /**< Mouse button number that went down (1 - 32) *$
>>
>> Evas_Point output; /**< The X/Y location of the cursor */
>> Evas_Coord_Point canvas; /**< The X/Y location of the cursor */
>>
>> void *data; Evas_Modifier *modifiers; /**< modifier
>> keys pressed during the event */ Evas_Lock *locks;
>>
>> Evas_Button_Flags flags; /**< button flags set during the event */
>> unsigned int timestamp; Evas_Event_Flags event_flags;
>> Evas_Device *dev; Evas_Object *event_src; /**< The Evas
>> Object which actually triggered t$ };
>>
>> ... event_src. we already have it. and we are doing it adhoc event by
>> event. this is why it should be core.
>>
>
>
> ------------------------------------------------------------------------------
> 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
> ------------------------------------------------------------------------------
> 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
>
------------------------------------------------------------------------------
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
