From: Brian M. <bma...@ma...> - 2005-09-12 19:53:48
|
Raster, I've been noticing that we often want to accept generic evas mouse events on edje objects (such as ibar icons, pager windows, pager desks, etc). So, we've been adding event objects and moving/resizing them along with the edjes and setting cb's on those. As this becomes more frequent, it becomes an overwhelming duplication of code, and makes things a little tricky when stacking is involved (pager wins e.g.) So, I was wondering if we could wrap all this event object business up in evas' smart object code so we don't have to duplicate it all the time. So, when an event cb is added to a smart object, we would (unless one already exists) create an event member object, and add the events to _that_ instead, and add the necessary hooks to keep it following the rest of the object properly. This would make smart objects behave even more seemlessly like primitive evas objects, and would only add the extra object overhead in the case where someone has actually set a cb on the smartobj (which means they would be adding their own event object without these changes). Any objections to adding this in at the evas level and saving us all a ton of work at the higher levels? -- rephorm |
From: Carsten H. (T. R. <ra...@ra...> - 2005-09-15 06:22:23
|
On Mon, 12 Sep 2005 14:58:51 -0500 Brian Mattern <bma...@ma...> babbled: > Raster, > > I've been noticing that we often want to accept generic evas mouse > events on edje objects (such as ibar icons, pager windows, pager desks, > etc). So, we've been adding event objects and moving/resizing them along > with the edjes and setting cb's on those. As this becomes more frequent, > it becomes an overwhelming duplication of code, and makes things a > little tricky when stacking is involved (pager wins e.g.) > > So, I was wondering if we could wrap all this event object business up > in evas' smart object code so we don't have to duplicate it all the > time. So, when an event cb is added to a smart object, we would (unless > one already exists) create an event member object, and add the events to > _that_ instead, and add the necessary hooks to keep it following the > rest of the object properly. > > This would make smart objects behave even more seemlessly like primitive > evas objects, and would only add the extra object overhead in the case > where someone has actually set a cb on the smartobj (which means they > would be adding their own event object without these changes). > > Any objections to adding this in at the evas level and saving us all a > ton of work at the higher levels? well theres several levels of stuff to do really. as i said in other mails. smart objects could do with cleaning up. a generic container that trap[s and then passes on or doesnt events to objects below woudl be good. in general with enevents i'd be nice to add filtering to events for objects so thnigs can selectively pass on, steal and whatever events for any object, smart or not. > -- > rephorm > > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ra...@ra... 裸好多 ra...@de... Tokyo, Japan (東京 日本) |