[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [E-devel] Evas Smart objects



On 7/2/06, The Rasterman Carsten Haitzler <raster@rasterman.com> wrote:
On Mon, 19 Jun 2006 01:17:03 +0200 "Jorge Luis Zapata Muga"
<jorgeluis.zapata@gmail.com> babbled:

> 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 get call would be useful and a good idea. :)

hi all and happy new year =)

ive retaken this thread to not add another one about almost the same
topic (Evas smarts) :)
i know the get call is indeed usefull, but im having another "problem"
with evas smarts, the member_add/member_del functions. Wouldnt be good
to have the smart class also define (if it wants) a member add/del
callbacks?

all smart classes define their own api to add a member in case they
want to track down/do something with the objects added/deleted which
is good, but imho isnt consistent because if someone uses the "normal
api" to do that (evas api) the smart object will be in a inconsistent
status. one solution is to do everything through evas api, do a
_member_add and the smart callback will be called.

If the smart also wants to add its own objects in case an object is
added it still has to differentiate in the callback if the object
added is its own or another, but isnt a problem i think =)

what do you think?


> 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.

well no - smart objects are not sub canvases. definitely not. they are  a
overgrown solution to people asking for "object groups" - a way to group
objects together and operate on them as a whole. since how a group would behave
on a move or resize can be so variable, i wrote a very generic mechanism that
doubled as a way to make new object primitives from existing ones, as there is
no way to provide a custom first-class object yet. setting layers of objects
once in a smart object is invalid. :)

> 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 :)

definitely wrong assumption. they aren't meant for sub-canvases really :)

> bye
>
>
> _______________________________________________
> 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)    raster@rasterman.com
裸好多
Tokyo, Japan (東京 日本)