Chady Kassouf schrieb:
> On 8/21/07, Peter Wehrfritz <[EMAIL PROTECTED]> wrote:
>
>> Simon TRENY schrieb:
>>
>>> Hi,
>>>
>>> I've seen in Evas.h that most of the methods of Evas_Smart_Class are
>>> marked as to-be-deleted in the future ("FIXME: DELETE ME"). This
>>> concerns show(), hide(), color_set(), clip_set() and clip_unset().
>>>
>>> I think it will be indeed a really great thing to do since when we
>>> implement these methods for a new smart-object, we basically always do
>>> the same thing (i.e clipping member-objects against the parent's
>>> clipper in clip_set(), hiding the member-objects in hide_set()...). It
>>> will also simplify a lot the code of Etk_Widget as I tried to make
>>> these things done automatically but since Etk doesn't have access to
>>> Evas internals, it is quite a mess.
>>>
>>>
>> I'm totally against the idea to clip all smart members to the smart
>> object geometry. I can understand that this is the common case in the
>> view of a toolkit author. But in fact there are many exception I can
>> think of. For example an animation that overlaps the geometry of the
>> smart object, a shadow that overhangs the area of an swallow part, etc..
>> In elitaire I use this for the cards. The logical card has always the
>> same size, but when you switch on shadows, the card image has an offset
>> outside of this area and only the shadow has the same geometry (position
>> and size) like the smart object. That make it very handy to handle
>> movements of the card and animations like lifting the card at the same
>> time.
>> I don't think we should sacrifice the power of evas smart objects
>> because of a common case that 90% of the smart object use. Think of the
>> remaining 10% percent. This cases need to be handled, too. You could
>> write an convenience object, maybe called evas_object_group, where you
>> only have to set the resize callback and the rest is done internally.
>> But please let the the smart objects as they are. There are many cases
>> where you need the versatility of them.
>>
>
>
> The proposal is NOT for clipping to the parent object's geometry, but to the
> parent object's clipper.
> Yes, your case if very valid, but if you're going that route, you probably
> will have your parent clipper account for the shadows by making it that much
> bigger to not clip the shadows.
>
>
Ah, then I misunderstood Simon. So you have a function
evas_object_smart_clipper_set() to set the clipper and control the
clipper on your own? That could work for me, but I still would prefer to
have this in an evas object group or something similar. I don't know,
however, if that makes the implementation too complicated.
Peter
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
