[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [E-devel] Evas Smart objects
Le Mon, 19 Jun 2006 01:17:03 +0200,
"Jorge Luis Zapata Muga" <email@example.com> a _crit :
> Hi all,
> i have some doubts-ideas about evas smart objects,
> 1. the API
> in order to add an object to a smart object you have to do
> _member_add(o, s) and to delete _member_del(o,s). On the code of both
> an evas smart object actually stores the members on a list but theres
> no function to retrieve them, Evas_List * _members_get(s), so when you
> code an evas smart obejct and you need to keep track of the objects
> you have, you need to duplicate the list and code a different function
> to do that.
A function called evas_object_smart_member_get() would definitely be
> 2. the implementation
> ive been playing with smart objects for evoak, so ill explain the
> case: my goal was to create a container, an evas objects container.
> the problem i see is that the evas smart objects where thought for a
> static environment, on the callback of a smart object add you create
> the static objects inside, store them on your list and when something
> happens (move, resize, whatever) you act accord with that and apply
> that to your internal objects. thats fine. but i thought the idea of
> the smart objects was to actually be a sub canvas of evas, so when you
> add an object: evas_object_add(evas) and then add it as a member of
> smart object it is no longer part of the evas objects but of the smart
> objects, so for example a layer change on that is actually a layer
> change inside the layers of the sub canvas, wich in fact the subcanvas
> is in one layer. but not in the evas canvas layers. another example is
> that when you move an object what is member of a smart object it
> should move relative to it, no relative to the evas canvas. dont know
> if i explain myself correctly :)
> so a problem with this is that if you want to move an object that is
> part of smart object you should call a different (own) function to
> calculate all the relative coordinates and move it there.
I agree with you. Making smart objects have their own objects
stack was a good step forward but smart objects still need to be a bit
First, a member object (a child) of a smart object (the parent) should
be visible only if the child and all of these parents are visible. So
we could remove the show()/hide() callbacks from the smart object API.
We should have the same thing for the clipping. The clipping object of a
smart object should automatically clip all the children of the
smart object. We could then remove the clip()/unclip() callbacks.
All those modifications could be done without having to change the
current API and the current behaviour.
Making the children's positions relative to the smart object is a bit
more complicated because we will have to rewrite all the existing smart
objects (won't be hard though). But I guess it would indeed be better
if the positions of the children were relative: we won't need to write
the move() callback, and I think it will probably be necessary for the
future implementation of blitting in Evas (but maybe I'm wrong on that
If all those modifications are done, we'll only have to write the
resize() callback to create a new smart object. And if the user still
wants to know when the smart object is moved or anything else, he could
still uses an evas callback.
The only problem I can see is that... it will need a lot of work and
time to spend on evas :)
Simon TRENY <MoOm>
> so my question is, the current aproach of evas smart objects in the
> correct way? or my use case is just an specific and doesnt make sense
> to change the behaviour of the smart objects?
> maybe a solution could be to add callbacks for a move, resize,
> layer_set, whatever, but not for the smart object but for the elements
> of a smart object.
> btw, if i made a wrong assumption about smart objects please forgive
> me :) havent used them a lot :)
> enlightenment-devel mailing list