Re: wip/apocalypses/apocalypse-1

[Piñeiro <apinheiro igalia com>]

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