On Tue, 4 Sep 2007 13:23:51 +0200 Simon TRENY <[EMAIL PROTECTED]> babbled:
> 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, ...).
actually i will eventually add that as a clip option. clip as now where each
object gets clipped individually - OR later, when option is there, render first
to buffer without color modifications (but with clipping) THEN modify as a
group (this will also imply that stacking will become continuous so if you have
non-clipped objects between clipped ones in the stacking layers - then this
won't work). but this is a "future plan" and smart objects could use the same
back-end or idea. buffers slow down rendering as we need to render to buffer
first, then take that - also if we keep buffers around it costs memory, so
nothing comes for free.
> 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 [email protected]
> > > 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) [EMAIL PROTECTED]
裸好多
Tokyo, Japan (東京 日本)
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
