Simon TRENY schrieb:
> On Tue, 21 Aug 2007 10:26:16 +0200,
> Peter Wehrfritz <[EMAIL PROTECTED]> wrote :
>
>
>> 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.
>>
> No, you'll still use evas_object_clip_set() to clip the smart-object.
> And in that case, the member-objects will be clipped automatically
> against the same clip object.
>
>
Oh, sorry for the noise. I thought you are going to implement this
(show, hide, color, etc.) via a rectangle clip. When I finally
(hopefully :) ) understand you correct, this asumption was wrong. Then
I'm fine with it.
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
