> Sevcsik András wrote:
>
>> Hi list,
>>
>> What's the purpose of esmart_container.c:442 line?
>>
>> evas_object_clip_set(el->obj, cont->clipper);
>>
>>
>> It clips the elements with the container, but I don't see a reason to do
>> so. My application needs elements to be able to drawn outside the container
>> (toolbar icons wich are zoomed), so I commented out that line and it works
>> fine now. Is it possible to modify esmart this way? If you prefer to make it
>> an option (with a function like esmart_container_clip_elements_set(con,
>> 0/1), i'll write a patch.
>>
>>
>
> There are many different types of semantics that a given smart class
> can give to 'clipping' - the class has a function to define just that.
>
> However, for most 'common' applications of smart classes, one sees
> a standard kind of semantics wherein 'clipping' a smart object is implemented
> as clipping all of its member objects - either directly or indirectly.
> The 'indirectly' part comes since some smart classes use a secret clip
> rect that clips all other member objs to define all sorts of things, like
> coloring of the smart, visibility, and such. It's a somewhat overloaded
> function these internal clip rects provide (not sure if esmart container
> does it this way though).
> Hence, if one wants to further clip the smart, it'd be implemented by
> clipping the internal clip rect they have, if one wants to color the smart obj
> one sets the color of the clip rect, or if one wants to show/hide the smart
> obj
> one shows/hides the clip rect (if an object is 'shown' but clipped by a rect
> which is 'hidden' then that obj will also be hidden).
>
> This is one common way that many smart classes define the semantics of
> "clipping", but you can certainly have others. I believe Gustavo was working
> on some extension of this that had more flexible such container smart classes.
>
One other very important aspect of the use of these 'secret' clip rect
objs used by some smart classes is of course when resizing their smart objects -
ie. when the smart objs get resized, the clip rect gets resized to be of the
same size, hence making all members be 'clipped' by the smart obj's size.
It probably wouldn't be a good idea to change the semantics of esmart
containers as that may break a lot of stuff (unless you manage to keep the
default
behavior as it currently is and just extend), and it really shouldn't be
necessary
for what you want.
You should be able to do what you want either by just letting your
container
be as large as you want to hold the zoomed-icons, or keep the container the size
of the un-zoomed-icons-region and when you do need to zoom them, remove them
from
the container... or implement your own specialty class to do what you want..?
____________________________________________________________
Summer Spa Sweepstakes
Enter for your chance to WIN a Summer Spa Vacation!
http://thirdpartyoffers.juno.com/TGL2141/fc/JKFkuJi7UbfNz8VIYtEkVCKFPBhd8IVHeJ0109LwaW4xGoJhtvjjCC/
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
