On Sat, 2007-08-04 at 18:05 -0400, Pierre-Luc Beaudoin wrote:
> Hi,
>
> I began porting Sofa to Clutter 0.4. Unfortunately it didn't work
> right off the box. I suspect clutter_actor_show_all() has a different
> behavior between 0.2 and 0.4. I have my actors grouped in 3 levels:
>
> MenuList -> Menu -> Label
>
> In 0.2, I only had to clutter_actor_show_all() on MenuList to have all
> the menu show up. Now in 0.4, after a good search ;), I found out I
> have to do a clutter_actor_show_all() on each menu.
in 0.2, clutter_actor_show_all() was recursive on every actor; in 0.3 it
was changed not to be recursive on ClutterGroup actors because you'll
get every single actor shown at the same time -- which may or may not be
what you want; for instance, you might add a "spinner" texture to your
group but decide for yourself whether to hide it or not.
you can override this behaviour, though: instead of directly using a
ClutterGroup, you can subclass it and override the ClutterActor
methods ::show_all() and ::hide_all() to be recursive; in Python it
means you have to provide a do_show_all() and a do_hide_all() methods in
your class, something like:
class MyGroup (clutter.Group):
def __init__ (self):
clutter.Group.__init__ (self)
def do_show_all (self):
for child in self.get_children ():
child.show_all ()
self.show ()
which will recurse through the children, and if a child is of type
MyGroup will do the same. so, in your case, both MenuList and Menu
should override the ::show_all() method.
> It might be a performance improvement, but I preferred the previous
> behavior... what do you think?
we are nearing 0.4, so further API churning would delay the release; my
personal take on this is:
* make clutter_actor_show_all() and clutter_actor_hide_all()
recursive on every container - except for the stage;
* add a CLUTTER_ACTOR_NO_SHOW_ALL flag to be set on actors
we absolutely don't want to show even when we call
clutter_actor_show_all();
this would solve the issue with the expected behaviour of a show_all()
method; for more complex behaviour, subclassing and overriding are
always an option.
ciao,
Emmanuele.
--
Emmanuele Bassi, OpenedHand Ltd.
Unit R, Homesdale Business Centre
216-218 Homesdale Rd., Bromley - BR12QZ
http://www.o-hand.com
--
To unsubscribe send a mail to [EMAIL PROTECTED]
