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.
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
