Jose O Gonzalez wrote:
On Mon, 12 Sep 2005 14:58:51 -0500 Brian writes:
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
This is in part one-half of the issue I tried to raise
earlier in my email regarding "Smart Objects"... and it's the
tougher half.
One might not really 'need' to add "event objects" to
a smart object - smart objects themselves could be made to
"feed" events, "respond" to events, etc..
Right now, they do little of this since they are not
considered to be in the list of 'event-objects' that the pointer
lies in, even though they can be set, or not, to "pass" events..
a somewhat complex state of affairs.
Making smart objs "own" their member objects, thus helping
to solve some stacking-order issues, raises the other question:
What then for event-handling?
Should the current model be maintained? Or should smart
objs attempt to have the same event model as say one sees in
window systems?
Jose.
I guess one possibility would be:
When an event cb is set on a smart object:
1) store the request callback function in the smart object
2) set an event cb on all of the member objects with an evas
internal cb function
3) in that internal cb function, call the callback set on the smart obj
That would eliminate the need for event objects, and would limit events
to areas actually covered by a smartobj member (instead of the entire
smartobj bounding box).
--
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
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
