On Tue, 13 Sep 2005 09:18:14 -0500 Brian writes:
> 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
>
>
[BTW - recall that in general there's no constraint relating
the geometry of a smart object to the visible geometrical extent
of its member objects]
It's a nice idea, and would likely go far to solve the
problem you're facing (something like this is already done
if the member objects have no callbacks set on them). But I
wonder how well it will work without the smart objects also
being able to "feed" events, etc.. ie, without their full
support for the general event mechanisms.
I believe that these kinds of issues will continue
to crop up unless the underlying model around smart objects
gets a clear and consistent semantics - internally, for many
of the general object related functions, smart objects are
functionally just 'not there'.
Smart objects attempt to span a large spectrum between
simple "container" or "group" like structures, and something
like a full "sub-canvas" structure.. and to do so as actual
canvas objects. Not an easy task.
Given an evas, one can have "evas-objects", ie. an object
of the given evas from which one can obtain another 'underlying'
evas (one which you would not need to get/set any engine info
structure) and add whatever evas primitives to that 'sub-evas',
etc.. Such an evas-object will display its sub-evas on the
initial given evas. But the objects of that sub-evas are not
'actually' objects of the initial given evas. By contrast, the
members of smart-objects (of a given evas) 'are' objects of the
given evas.
I have the feeling that unless smart-objects adopt most
of the semantics that is used in window systems (in dealing with
the parent/child relationship), it is likely that they will
continue to be 'problematic' in one sense or another, for
someone or other's needs or expectations.. :(
Jose.
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
