Re: [E-devel] R: Re: Evas_Event propagation

2008-01-13 Thread The Rasterman
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
 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)[EMAIL PROTECTED]


-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just 

Re: [E-devel] R: Re: Evas_Event propagation

2008-01-10 Thread Dave
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
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] R: Re: Evas_Event propagation

2008-01-07 Thread Caio Marcelo
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
:-)


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.

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
From e008ce0b388e533f08f70f3a7699a114610cbe12 Mon Sep 17 00:00:00 2001
From: Caio Marcelo de Oliveira Filho [EMAIL PROTECTED]
Date: Fri, 4 Jan 2008 18:35:23 -0300
Subject: [PATCH] evas_events cleaning up, part 1

My focus is in the end have a good way to feed specific Evas_Objects with events, as previous
discussed by the folks in the mailing list.

- Extracting the functions that fill Evas_Event structures, this avoided a bit of repetition.
- Separating some functions to make easy creating public API event feeders per object.
---
 src/lib/canvas/evas_events.c |  520 +++---
 1 files changed, 236 insertions(+), 284 deletions(-)

diff --git a/src/lib/canvas/evas_events.c b/src/lib/canvas/evas_events.c
index af853e2..ba9bceb 100644
--- a/src/lib/canvas/evas_events.c
+++ b/src/lib/canvas/evas_events.c
@@ -10,7 +10,7 @@ evas_event_passes_through(Evas_Object *obj)
if (obj-smart.parent)
  {
 	int par_pass;
-	
+
 	par_pass = evas_event_passes_through(obj-smart.parent);
 	obj-parent_cache_valid = 1;
 	obj-parent_pass_events = par_pass;
@@ -20,59 +20,72 @@ evas_event_passes_through(Evas_Object *obj)
 }
 
 static Evas_List *
-_evas_event_object_list_in_get(Evas *e, Evas_List *in, Evas_Object_List *list, Evas_Object *stop, int x, int y, int *no_rep)
+_evas_event_object_list_in_get(Evas *e, Evas_List *in, Evas_Object_List *list, Evas_Object *stop, int x, int y, int *no_rep);
+
+static Evas_List *
+_evas_event_object_list_in_get_by_object(Evas *e, Evas_List *in, Evas_Object *obj, Evas_Object *stop, int x, int y, int *no_rep)
 {
-   Evas_Object_List *l;
+   if (obj == stop)
+ {
+	*no_rep = 1;
+	return in;
+ }
 
-   if (!list) return in;
-   for (l = list-last; l; l = l-prev)
+   /* In all this cases an object (and its possible smart children)
+  is not suitable for receiving the event. */
+   if 

Re: [E-devel] R: Re: Evas_Event propagation

2007-12-20 Thread Nathan Ingersoll
I believe we had a discussion about this a little while back and
thought that the best way to handle this situation was to create
wrappers for feeding the events into individual objects. That way you
could put an overlaying object that intercepts the event, decides how
to handle it, and then feeds it to other objects when appropriate.

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.

On Dec 20, 2007 9:31 AM, Dave Andreoli [EMAIL PROTECTED] wrote:

 - jose ogp [EMAIL PROTECTED] ha scritto:
  Dave wrote:
 
   Hi all,
   I'm in trouble with the evas event system  :(
   Working on esmart_container to make an iphone-like scrolling list
   (with friction) this is the situation:
   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...
  
   Some idea?
   In other toolkits this is done by returning a NULL value from the
   callback...
 
Did you make any progress with this? Evas' event model is
  pretty basic, though you can build on top of it in various ways.
I think andruko (of canola fame) may have done something
  similar.. maybe he, or others involved with the gui toolkits, can
  give you ways they've used for dealing with things of that sort.
 

 No progress for now :(
 I'm trying to hack the way evas handle events, but I prefer to find a solution
 without break all the apps/libs that use Esav_Event.
 I will contact the guys at INdT, thanks
 Dave


  -
  SF.Net email is sponsored by:
  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
  enlightenment-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


 -
 This SF.net email is sponsored by: Microsoft
 Defy all challenges. Microsoft(R) Visual Studio 2005.
 http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel