One of the core tenets of the Clutter API design since the 1.0 days, six years ago, is to use delegation whenever possible. We have ClutterLayoutManager for layout management; ClutterContent for content display; ClutterAction for event handling; and ClutterEffect for content post-processing.
Up until now, the Clutter API, lacked a way to delegate mapping an actor state to a separate state object — something like a “model/view” split. Sure, we had ClutterModel to store some state in a tabular form rows of data organized in columns of attributes, but there was no way to represent that data, and, more importantly, the data itself was decomposed into separate values, with little to no effective or efficient way of grouping it into proper objects, unless you shoved object instances into the model.
The history of ClutterModel is also one fraught with expedient. The reason it was introduced in Clutter 0.6 was because of the lack of a corresponding data structure in GLib itself; the only similar data structure could only be found in GTK+ — i.e. GtkTreeModel. Given how tied GtkTreeModel is tied to GtkTreeView, we simply could not provide a view actor or interface inside Clutter, at the time. We did add simple view actors in layers above Clutter, like Tidy or Mx, but they were tailored to specific use cases and thus unsuitable to be reintegrated back into the low level API.
Since the 0.x days, there have been many changes in the GNOME core platform. One of those changes is GListModel, available starting from GLib 2.44. The list model API is fairly simple, and geared towards collections of GObject instances, which can then signal changes through property notification. You can see this in effect in the GtkListBox API.
For all these reason, I’ve added two new methods to the actor class, available starting with the 1.24 stable cycle, that allow you to bind a GListModel to a ClutterActor, and create children that represent objects inside the model:
clutter_actor_bind_model()— this function lets you control the whole child creation phase through a simple delegate function; it’s the obvious port of theGtkListBoxmethod linked aboveclutter_actor_bind_model_with_properties()— this is a convenience function that takes over the child actor creation, and lets you specify the type of the children to create, as well as the properties to bind, in a simple way
Clutter ships an example of this new functionality; while it may seem overly verbose, it shows how to neatly encapsulate model, view, and controller into three separate classes, and let the Clutter and GObject API take control of the relationship between the types. This should help you when modelling your UI and your logic code, and improve the maintainability of your application.