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. -- Chady 'Leviathan' Kassouf http://chady.net/ ------------------------------------------------------------------------- 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
