> > I disagree here.  You are correct in that 95+% of cases are just
> > hide/show the clip and the like.  However we have a number of widgets
> > that do things like stop animations, release resources or similar
> > actions on hide calls, also more complex widgets delay layout
> > recalculations until the show call.
> About doing stuff on show, you'll still be able to do this. You'll just
> need to have a callback to the SHOW event of the smart-object (with
> evas_object_event_callback_add()).

The advantage of doing stuff with the smart callback is that it is
called first.  There are no guarantees that what order event callbacks
are invoked, at least not any useful ones.  If I recall correctly there
were discussions of moving event callbacks to asynchronous events
(obviously a massive API change).  

> As for evas_object_hide(), maybe you just shouldn't call it for what
> you are doing. You could have a function my_smart_object_hide() that
> will do all the animations, and that will finally call
> evas_object_hide() on the smart-object at the end of the animations.

That idea breaks the whole idea of smart objects.  They are supposed to
abstract the whole idea of Evas_Objects so there is a uniform API.  
[I still have code here from pre-smart-object evas here, and they all
have <widget>_hide, <widget>_show, <widget>_move calls etc].  Stopping
animations or releasing some resources.  

Just to be clear, I'm NOT referring to animations being triggered on a
hide call, just about stopping internal work on the hide.  So I think my
original post may not have been clear on this, as I believe we are in
agreement on these points.

> Imho, evas_object_hide() should really hide the object. And since
> smart-objects have been designed to form a logical group from compound
> evas-objects, evas_object_hide() should hide the smart-object and all
> its member-objects. It wouldn't be coherent to have
> evas_object_visible_get(smart) returning 0, and still have a
> member-object being visible. The state of the member-objects should
> automatically inherit from the state of their parents if we want to
> keep things logical imho.

I agree with this, evas_object_hide doing things aside from hiding
objects is (generally) stupid.  But releasing resources, or to stop
doing work because it's not visible is useful (waiting for pixel_get is
good for videos, but not for a lot of other things).

        Regards,
        nash



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

Reply via email to