Stinging Velvet

Clutter – If release 0.4 rocked hard, release 0.6 of Clutter will blow your mind away. Just to list some features landed in the past couple of weeks after ClutterScript got in:

  • new event handling, borrowing from the W3C DOM event – that is, two event phases: capture, which traverses the scene from the stage to the actor that received the event, and bubble which traverses the scene from the actor to the stage. You can block the event chain in any point of both phases by simply returning TRUE in the signal handlers (like GTK+); kudos to mallum and Pippin
  • improved text scaling, at least for downscaling at ~50%; kudos to Pippin
  • build and test on win32 using the SDL backend, complete with VS2005 build files; kudos to tf
  • time-based timelines, so you can define a ClutterTimeline by giving its length in milliseconds; and without even breaking the API.

Still, there’s plenty more coming – so keep looking at trunk.

JSON-GLib – The code base has been consolidated a lot while working on ClutterScript, so I feel confident about making a release of the out-of-tree repository. The release is bagged, tagged and signed as json-glib-0.2.1 in the git repository1. You can grab the tarball here. Work on seamless GObject-JSON (de)serialization will continue in the master branch towards a 0.4.0 release. Update@2007-10-16T23:30+0100: obviously, as soon as I got back home and checked the repository I found two bugs in the generator code; hence, brown paper bag release 0.2.1. Tarball, documentation and tag updated.

  1. As usual, at []

Rome Wasn’t Built in a Day

People often arrive on the #clutter channel1 with troubles building Clutter from SVN: dependencies, installation in non-common prefixes, etc.

Luckily, GNOME has Jhbuild, which is easy to set up2 and also allows custom modulesets for handling dependencies inside a separate root – to avoid messing up your box.

So, if you want to play with Clutter, here’s two Jhbuild modulesets:

  • clutter-0.4.modules – for the stable branch of Clutter, if you are developing applications
  • clutter-0.6.modules – for the development branch of Clutter, if you want to contribute to Clutter itself, or you want to write bindings for it

Just download the moduleset file of the branch you want to use, copy it into the modulesets directory of the Jhbuild checkout and then:

  jhbuild -m clutter-0.4 build pyclutter

or, if you have a fresh checkout of Jhbuild, simply do:

  jhbuild -m build pyclutter

thanks to Frederic Peters for fixing remote modulesets and pointing this out

The command lines above will build the stable Python bindings for the stable branch of Clutter, fetching all the needed dependencies. If you’re stuck on some external dependency, though, feel free to drop into #clutter and ask for help3.

Update@2007-10-12T17:51+0100: I’ve added the following meta-packages:

  • meta-clutter-core, depending on Clutter
  • meta-clutter-suite, depending on meta-clutter-core, Clutter-GStreamer, Clutter-GTK+ and Clutter-Cairo
  • meta-clutter-python, depending on meta-clutter-suite and PyClutter

You can use the meta-packages to pull in everything you need. As soon as I figure out a way to reliably depend on the other languages runtime environments, I’ll probably add their own meta-packages and a meta-clutter-bindings as well.

Have fun!

  1. IRC: – join today! []
  2. the wiki page linked has it running in less than ten easy steps []
  3. be sure to specify which distribution you have []


Today I committed to Clutter trunk ClutterScript, the initial support for defining the scenegraph using external files. You can think of it as the GtkBuilder equivalent for Clutter.

During the 0.3 development cycle we considered using XML and JSON, and opted for the latter because while XML is quite easy for applications to write, JSON is more geared towards human to read1. Also, JSON syntax is really parser-friendly, with only three barewords and six symbols.

Another nice thing about JSON is that many high-level languages already have some JSON module, so manipulating data streams would be quite easy for, let’s say, Perl or Python before feeding those streams to Clutter.

Defining a simple scene with JSON and ClutterScript is quite easy:

  "id" : "main-stage",
  "type" : "ClutterStage",
  "fullscreen" : true,
  "children" : [
      "id" : "red-button",
      "type" : "ClutterRectangle",
      "x" : 100,
      "y" : 100,
      "width" : 100,
      "height" : 100
      "color" : "#ff0000ff"
      "id" : "green-button",
      "type" : "ClutterRectangle",
      "x" : 300,
      "y" : 100,
      "width" : 100,
      "height" : 100
      "color" : "#00ff00ff"
      "id" : "blue-button",
      "type" : "ClutterRectangle",
      "x" : 600,
      "y" : 100,
      "width" : 100,
      "height" : 100
      "color" : "#0000ffff"

This will draw a red, a green and a blue square, 100×100 pixels of size, inside a full screen stage.
You can then retrieve the "main-stage" object (as well as any other object using its id) and connect signals and manipulate them with the usual Clutter API.

At the moment ClutterScript is not 100% complete – I still need to add support for defining behaviours (mostly a matter of defining an object syntax); complex properties parsing; merging (and, possibly, unmerging) of “snippets” of objects. Plus, obviously, more sanity checks in the scene building code.

To parse JSON there are a few C libraries, but I opted for writing a GObject-based one – which, in one of my usual moments of lack of originality, I called JSON-GLib. Clutter uses an in-tree copy because I might need API changes to make Clutter parsing code easier, but the library is already auto-tooled, tested and 100% documented (it is missing GObject deserialization, but that will have to wait). JSON-GLib is released under the terms of the LGPL and it’s available in my personal git repository, which you can clone with the usual:

  git clone

Update@2007-10-09T15:07+0100: Just landed in trunk: defining behaviours (not every type, complex types like the path-based ones are still to be implemented), merging tests and more sanity checks. Defining a rotate behaviour boils down to:

  "id"          : "rotate-behaviour",
  "type"        : "ClutterBehaviourRotate",
  "angle-begin" : 0.0,
  "angle-end"   : 360.0,
  "axis"        : "z-axis",
  "direction"   : "cw",
  "alpha"       : {
    "timeline" : { "loop" : true, "num-frames" : 300, "fps" : 60 },
    "function" : "sine"

Really soon now: all behaviours, complex properties and more.

  1. obviously nothing prevents adding an XML parser, and use both []