On Sat, 25 Aug 2007 12:41:02 +0900,
Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]> wrote :
> On Tue, 21 Aug 2007 00:58:58 +0200 Simon TRENY <[EMAIL PROTECTED]>
> babbled:
>
> > 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().
>
> mmm - basically those can probbably be handled by intercepts or
> events. color_set, clip_set/unset should "just work" as expected. i
> just can't see any other really good reason to not have them do the
> obvious - same with show and hide.
>
> > 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.
>
> yup. so instead of creating a clip object and add it to the smart -
> then clip all smart members to the clip to handle color_set - is
> tedious.
>
> > I'm willing to try to implement those things in Evas, but first I'd
> > like to be sure of the behaviour to respect:
> >
> > - A member-object should be "really" visible only if its parent is
> > visible and if it is set as visible (evas_object_visible_get() ==
> > 1). It would remove the need for show() and hide()
>
> correct. the parent smart object visibility should be a "master
> control" for all children. hidden children will never be visible -
> shown children are visible ONLY if the parent is visible too.
>
> > - A member-object should be clipped by the intersection of its
> > clipper and of its parent's clipper. It would remove the need for
> > clip_set() and clip_unset()
>
> correct. same with clip colors. a smart object's parent color should
> multiple all child objects like a clip object's color multiplies all
> clipees (objects clipped by the clip object). basically the smart
> object is an implicit parent clip etc. proxy for children.
>
> > - The member-objects' color should be automatically multiplied by
> > its parent's color at rendering (--> no more need for color_set()).
>
> correct.
>
> > Actually, I'm not sure about this last point. What if the user
> > would absolutely want to have a member-object always green for
> > example, regardless to the color of its parent? I can see a use for
> > this: in estickies, the window is semi-transparent while the text
> > is opaque, and yet, the text is a member-object of the window.
>
> no - always. parents should control children. fading out a button
> that contains an icon won't work unless you color multiply always.
>
> > Are you ok with this?
> > Do you have any other requirements for the smart-objects?
>
> currently- not really. i know this thread has gone on a bit - but the
> arguments for show/hide etc. are there, but can be done by events (on
> a hide - stop all animation - or even destroy child objects to save
> memory/space and on show create them again - but do via an intercept
> or event callback).
>
> as a fist step - lets not remove, but if show/hide etc. are NULL -
> then apply the above default behavior.
I agree with this. I'll try to look at this in the next few days.
Btw, is there any plan to add the ability to render a smart-object into
a buffer with Evas? It would solve some problems with clip/color-set
with alpha != 255 (for example, if two member-objects are overlapping),
and it could also be used to improve performances for widgets that use
scrolling (list, iconbox, textblock, ...).
Simon
>
> > Regards,
> > Simon TRENY <MoOM>
> >
> > -------------------------------------------------------------------------
> > 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
