From: Peter W. <pet...@we...> - 2007-08-21 09:46:19
|
Simon TRENY schrieb: > On Tue, 21 Aug 2007 10:26:16 +0200, > Peter Wehrfritz <pet...@we...> wrote : > > >> Chady Kassouf schrieb: >> >>> On 8/21/07, Peter Wehrfritz <pet...@we...> 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 |