On 8/20/07, Simon TRENY <[EMAIL PROTECTED]> wrote:
> 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 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()
> - 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()
> - The member-objects' color should be automatically multiplied by its
> parent's color at rendering (--> no more need for color_set()).
> 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.
>
> Are you ok with this?
> Do you have any other requirements for the smart-objects?
I had this in my python bindings, but users were able to re-define
these methods (they were just default implementations), but I removed
most (clip_{set,unset}, color_set) because Kenneth and myself were
having misunderstanding problems... too often we were trapped in
"bugs" related to this... :-(
bugs here are not related to code, but what you expect it to do and
it does something else, like apply color to smart and smart change
color of inner rectangles instead of modulate it.
it's related to that change I proposed and applied to Edje, which
raster later reverted. The common sense was that color_set() on Edje
(and here SmartObject) have no pre-defined behavior (do nothing), if
you want to change the color (to do fade-in/out effect), you better
make these clipped to a rectangle and change its color.
--
Gustavo Sverzut Barbieri
--------------------------------------
Jabber: [EMAIL PROTECTED]
MSN: [EMAIL PROTECTED]
ICQ#: 17249123
Skype: gsbarbieri
Mobile: +55 (81) 9927 0010
-------------------------------------------------------------------------
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
