On Thu, 10 Jan 2008 14:40:41 +0100 Dave <[EMAIL PROTECTED]> babbled: being able to feed evas events to a specific object is also useful- it's actually easy to do, BUT i think the cleaner way for this as my previous mail said - is via being able to selectively drop some events from repeating through an object (or forcing them to repeat) in some cases, and in others to feed an event into evas to a specific object OR feed it "under" and object - eg store the mouse down/up co-ords then feed a fake event just below a specific object so it then falls down to whatever objects are underneath as if it were a normal event.
> Caio Marcelo ha scritto: > > On Dec 20, 2007 12:36 PM, Nathan Ingersoll <[EMAIL PROTECTED]> wrote: > > > >> I think that there was some consensus that the API to feed the objects > >> events would be a good addition, but I don't think anyone got around > >> to implementing it. > >> > > > > Last days I've tried to come up with such API, in > > src/lib/evas_events.c. I did two > > things mainly (1) refactor a little bit the code there; (2) add the > > "public feeders" for mouse_up and mouse_down. Even if we don't get a > > consensus about things in patch (2), I think after some review the > > patch (1) is benefical. So I can commit patch (1) if it's OK. Please, > > if any of you understand about src/lib/evas_events, review this patch > > :-) > > > > > This is a must have in cvs !! never seen others toolkit without a way to > block, feed events. > But I'm not in touch with that file to review :( > > And now follows a long story (which might be of Dave's interest)... ;-) > > > > My main motivation for giving a try doing this public API to "feeding" > > events directly into Evas_Objects was the same as Dave, quoting him: > > > > Dave wrote: > > > >> I have a trasparent evas_object (big as all the container) used > >> to grab mouse events. When you click & drag the mouse I make the > >> container scroll. The objects of the list also need mouse events > >> so I used evas_object_repeat_events_set(cont->grabber, TRUE); > >> to pass the mouse events. > >> > >> The problem is that I want to 'repeat' the events only when is not > >> a dragging operation. > >> In the grabber mouse,down callback I need to stop the propagation > >> of the event to the object below... > >> > > > > Here's how I solved this once: > > > > Python-etk binding has a List widget implementation (which need a lot > > of "love" yet but works) to serve as example of creating new widgets > > directly in Python. The renderers in the list (Edje objects) that > > follow a special convention, they must have hit areas but don't use > > the mouse events. The List itself (actually the "visible row") will > > listen to these mouse events and dispatch accordingly. > > > > In the end, an Edje renderer you just have to implement those methods > > pressed(), clicked(), unpressed() which pass the "hit area" (the part) > > as argument. So you can use your programs and process them correctly > > (e.g.: if its a click in the part "button_area", emit the > > "button_clicked" signal). > > > > Notice: I can do things like "pressed" / "unpressed", that behaves > > differrently for a non-kinetic-like list. For instance, if my row has > > a text and a button, if I press the button [it will call pressed() in > > my renderer] and move up up up, it will interpret this not as click, > > but as a drag and call unpressed() properly, even if I didn't > > unpressed the _mouse_ button. This allows you use sensitive areas to > > drag. > > > > But I'm having hard time figuring out something like this behaviour > > being implemented with the "feeders" or an solution like "stop the > > event processing if we return 0". > > > IMO "stop if return 0" is the best solution to have. Because it's > simpler to use. > > So, assuming that we have all the feeders (I can finish the missing > > ones if people consider them worthy to have), how to reproduce this > > pressed"/"unpressed"/"clicked" in a kinetic list? Ideas? > > > > We could feed a MOUSE_OUT event to do that "unpressed" thing, but it's > > a little strange since the mouse won't be OUT. And I'm not sure > > whether DOWN/UP (in Edje) keep states and stuff like that. So we would > > need to call UP too, but this can't trigger a CLICK. > > > > > > Cheers, > > Caio Marcelo > > > Absolutely we have to add this to evas :) > Bye > Dave > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > _______________________________________________ > enlightenment-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
