1. Apocalypse 2

1.1. Apocalypse

or Layout is not as bad as it sounds.

All actors with a child can either handle the size negotiation for layout invalidation directly or, better, use a Layout Manager delegate.

Layout managers are responsible for requesting the preferred size of the children of an actor, and assigning them the available size.

Animation between states should be possible by interpolating the current allocation and the new allocation, transparently from the layout manager's perspective - i.e. no additional code should be necessary when implementing a ClutterLayoutManager.

1.2. Exegesis

A Layout Manager is a delegate class for implementing layout policies for children of a ClutterActor.

Clutter already has a ClutterLayoutManager class which takes over:

preferred width
preferred height
allocation

Plus layout properties through the ClutterLayoutMeta class:

type query
creation
destruction
query for the (actor, child, layout) tuple

There is also an animation API based on the assumption that animations are transition changes driven by a timeline and a progress function, and that the allocate() implementation should just interpolate between the initial and final states.

The animation API is generally enough for a simple easing between states, but it has some warts:

it exposes ClutterAlpha in the API, when we want to get rid of that class in the future (see the 5th Apocalypse);
it considers animations as black boxes, and thus leaves a lot of boilerplate to be implemented by its subclasses;
there is little to no integration with the current Animation Framework: there is no way to associate state machines to an animation.

Most of the Layout Manager API can be left as it is, as it provides a proper delegation framework to implement actors with a layout policy by satisfying the principle of least astonishment for application developers and satisfying the API contract in the base ClutterActor class that is going to use the delegate.

The main goals for a revised Layout Manager class are:

the API should provide enough logic to couple a physics engine with the scene graph, instead of using a fixed layout manager, and have the physics engine just set the fixed position and size of each child at each frame.
it should be possible to have a layout manager interpolating between two very different states, e.g. a grid and a list view, without any more complexity than pre-computing the two layouts and interpolating between them.

1.3. Synopsis

TBD