On 01/10/2012 12:13 PM, Emmanuele Bassi wrote: > - Implementing Actor and Container > > ClutterActor implements the ClutterContainer interface by default. if > you have an actor that implements the Container interface most likely > you can drop every custom Container vfunc implementation and the actor > class will behave exactly the same.
Good to see that implementing the container stuff on CallyActor made sense. Thanks for update also CallyActor code. Once the branch is merged I will try to remember to remove the container implementation notes, as they would become obsolete. > > - Actor can be instantiated > > the base Actor class now knows everything there is to know about its > children, so there is no need for it to be abstract any more; a > ClutterActor instance behaves like a ClutterGroup by default, and if you > don't override the paint() virtual function (or if you chain up) the > default implementation of it will automatically paint the Actor's > children. the ClutterGroup API has been deprecated — the type, sadly, is > needed for ClutterStage. I guess that the same applies to CallyGroup. Right now I could reduce/nuke most of that implementation, but I would require to keep CallyGroup type to avoid a ABI breakage (as right now CallyStage is a CallyGroup). Right? > - Subclassing ClutterActor > > all the changes above allow you to avoid subclassing ClutterActor except > in special circumstances — essentially only if you have a special paint > sequence. it is strongly recommended to chain up to the newly added > default implementation of the paint() virtual function — though it's > still entirely possible to just implement iteration over the children > using the Actor API. > > there are other additions in the branch, like the background color > property for each Actor (which allows us to deprecate ClutterRectangle); > the margin properties; and the horizontal and vertical alignment for > children. all in all, ClutterActor should become more rational, more > easily usable out of the box, and reduce the amount of subclassing > needed to make Clutter work. Is there any tentative list with the ClutterXXX planned to be deprecated? BR -- Alejandro Piñeiro Iglesias _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list