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