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
