On Tue, 21 Aug 2007 08:50:46 +0200,
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.
You're right, member-objects should not be clipped to the smart-object
geometry, but, I never said they would! I only talked about clipping
the member-objects against the smart-object clipper, if there is one.
This is definitely not the same, and it makes sense imho (if you clip a
card against a rect, you want the shadow to be clipped too). But you
will still be able to have parts outside of a Edje group.
Simon TRENY <MoOm>
>
> 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
>
-------------------------------------------------------------------------
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
