Good Intentions

unique: this morning I released version 0.9.4 of libunique, everyone (least) favourite library for writing single instance applications. it’s mostly a bug fixing release, and since I’ve decided to release 1.0.0 soon, this is also the first release candidate for the 1.0 milestone. I’ve also moved the git repository to github, so you can clone it with:

  git clone git://

I plan to add back a new x11 backend for the 1.2 release, targeting small embedded environments were D-Bus might not be an option, and support for a --replace command line switch. after that, I’ll try to get the same functionalities into GLib/GTK+, as part of the future “desktop platform” module.

Clutter: I did a 0.6.2 release of both the core and the Python bindings, but things are afoot in trunk. we recently landed the multi-stage branch, which means that you’ll be able to create multiple windows and multiple GtkClutterEmbed widgets per application with Clutter 0.8. we’re also about to land the massive COGL rewrite that Ivan Leben of ShivaVG fame did — which will make the GL and GLES abstraction more powerful, will reduce the code duplication and in general will rock your world. Neil Roberts has been doing loads of work on the native Win32 backend: he not only made it possible to run Clutter on WGL, but also use the GtkClutterEmbed on Windows natively:

GtkClutter on win32

now, only the Quartz backend is missing the party — hint hint, nudge nudge.

OpenedHand: we’re hiring!

Rhyme the rhyme well

Jason, it’s not just the canvas: writing a simple 2D canvas is trivial — that’s why a lot of applications end up writing their own homegrown one.

The hard bits are the animation framework, the event handling and down to the integration with the existing platform. A generic canvas is hard, and you probably don’t want it to be developed inside gtk+ (not even for 3.0) — just like Cairo is not developed inside gtk+ but supersedes part of gtk+’s API.

As for 3D acceleration — I’m obviously biased here, so everyone should take what I write with a graintruckload of salt — but I maintain my view that if GNOME (and Linux) started heavily pushing towards more support for OpenGL, then we could get more market share ((think Compiz, and how many more users it brought home just with a spinning cube)), more visibility and thus more leverage to make the currently closed source drivers more open. Intel understood this; AMD is now getting it; I’m pretty sure nVidia will — or they will be simply pushed into irrelevance by the open drivers developed by the community ((unless you are a gamer, and need the very best card as soon as it’s out just to play Crisis)). Let’s face it: other platforms and toolkits are pushing heavily on hardware accelerated 3D effects.

Let’s start aggressively work to get the platform into the XXI century.

update@2008-10-11T12:21+0100 — just as a sidenote: if you have a good CPU, Mesa and software rendering, Clutter will work. It won’t be fast for some operations (like scaling and, possibly, rotating), but in that case you should probably start contributing to Mesa to make it fast (there’s a lot of room for improvement).


second and third day of the hackfest, edited on day five

on tuesday, Behdad and I started working on OpenGL integration inside GTK+. as stated multiple times on the Bugzilla entry, what we both would like is a Cairo-like integration of GL inside the available drawing systems in GTK+. in short: not a specialized widget like GtkGLArea, which would make it difficult — or plainly impossible without jumping through a long series of hoops. in flames. tied. and blindfolded — to integrate GL inside existsing projects; and not the incredible API dump that GtkGLExt is.

the design we mostly agreed on was a shared object inside GTK+, containing the GL context abstraction object, and two simple calls to delimit the drawing code, wait for vblank and swap the GL buffers. plus, an easy to use wrapper around the texture_from_pixmap extension, to allow drawing with cairo on a Pixmap and then have it pushed into the GL pipeline.

Carl arrived on wednesday, and partecipated at the scene graph BoF we held. the BoF itself was pretty straightforward: we read the slides that Havoc sent on the mailing list and discussed the various points. we all agreed on a lot of points — and we tried to define the problem space more deeply ((We did not always succeed in this, but the issue at hand is quite large and it’s understandable)). being there, I could bring to the table my experience in the past two years ((It’s really two years? holy crap! The time really flew…)) with the design and implementation of Clutter. some of the attendees were already familiar with it — something very satisfying — and I could expand some points in Havoc’s slides about Clutter that have been recently fixed or are going to be fixed in this cycle. the biggest point is that the scene graph should integrate with Cairo, in order to allow applications and people to gently merge both the 2D drawing of surfaces into a full 3D environment; I’ll leave to Carl to explain the Cairo side, because he’s obviously better at this than I am. :-)

the operative result of the scene graph discussion was that Clutter emerged as an already powerful and established solution for this problem space, and given that it already nicely integrates with GTK+, we can work towards the common goal of making it “the GTK+ canvas”, outside the actual library so that it can grow unrestrained and experiment in new directions.

Let It Take You

Murray, just a short reply to your points:

I sometimes feel I’d like to just put actors on a rail, twist that rail about, connect some actors together with struts or springs, start them moving, let the user push and pull them around within constraints, and trigger extra behaviour when they reach certain positions, or reach each other.

What you want is a physics engine hooked up into Clutter; it’s possible, Pippin has been doing some preliminary work on it, and it would solve the more “physical” interaction model. But it’s not always what you want your UI to look like and it’s not always a good model to employ, especially if you cannot interact physically with the UI – like shaking it, rotating it, use multi-touch surfaces.

Clutter is now a very basic API.

You make it sound like it’s a bad thing. Well, it’s not: it’s exactly what we want it to be like. No constraints on the UI structure or behaviour — those belong to toolkits developed on top of Clutter. Like Tidy, which is a shared library (it even installs a pkg-config file), but it will not be released as a tarball because we’d like to keep it as an experimental ground, read: breaking stuff, to see how and what should Clutter provide to implement an accelerated and animated toolkit. Also, as you note, in embedded environments you’ll want to style and create your entire stack: instead of raping and twisting GTK+ themeing until you don’t know that you’re using GTK+ anymore — and losing a lot of time in the process — you can use a standard low level API and develop your toolkit on top of it. It’s not optimal, but I think it’s a step in the right direction to make the GNOME mobile stack a lot more useful and flexible.

Neither you or Clutter should want to reimplement the huge amount of UI logic that is, for instance, in GTK+

That is why you can embed Clutter inside a GTK+ application, and hopefully you’ll soon be able to embed GTK+ widgets inside Clutter.

In short: Clutter was never meant or designed or developed to be a complete replacement for GTK+ on the desktop. On the desktop is an API for allowing hardware accelerated UIs embedded into current applications (photo slide shows for Eog; music library browsing for Rhythmbox; login user browser for GDM; and these are just the first items that come to mind). In the mobile environment arena, Clutter is meant to be used as a cornerstone – along with GLib, GStreamer and the rest of the GNOME mobile stack – for developing a new kind of UI, where the desktop guidelines and style don’t apply.

Travelling Band/Back

finally, back at home after FOSDEM 2008. the last leg of the trip back from Bruxelles has been exceptionally longer because the London Metropolitan Network on weekends is, apparently, made of fail.

the Clutter talk on saturday went, in my opinion, quite well; lots of people listened to my ramblings and watched my simple slide show. about the talk: it was my first with a slightly modified Lessig method approach and I have to say that it’s been a very satisfactory experience – nonetheless because it removes the need to put slides online, which I never end up doing anyway ((I’ve got a git repository with the small application I wrote to give the talk with, so if you want it you can always ask me for the URL to clone)).


I’ve just sent this to the Clutter mailing list, but I guess that more exposure is fine

as some of you might already know, we have started working on a reference “toolkit” based on Clutter called Tidy.

Tidy is a simple library containing some useful actors and interfaces which can be used by applications developers; it aims to be simple and yet provide some high-level classes that Clutter won’t provide.

it is by no mean complete, or aiming to replace other toolkits; you can think of it as a reference implementation for a toolkit based on Clutter.

Tidy works as a standalone toolkit, but it can also be used as a copy-and-paste repository, like libegg for the gtk+ stack; because of this, it doesn’t provide any kind of API or ABI guarantee, and it probably won’t be released in form of tarballs. it can be seen as a constant work in progress.

right now, Tidy is composed of these classes:

  • TidyActor – a base actor class, implementing stylable actors, with padding and alignment
  • TidyButton – a simple button class
  • TidyFrame – a container capable of aligning its only child
  • TidyListView – a list view using ClutterModel to introspect its structure and contents
    • TidyCellRenderer – base cell renderer class
    • TidyCellRendererDefault – default cell renderer
    • TidyListColumn – base column class
    • TidyListColumnDefault – default column
  • TidyTextureFrame – a texture that efficiently clones a background image so that it can stretch the entire size allocation
  • TidyProxyTexture – a texture class that efficiently caches the source file
    • TidyTextureCache – a cache for textures loaded from on-disk data
  • TidyTextureReflection – an actor using GL to compute a reflection of the parent texture (imported from the toys)
  • TidyStylable – base interface for stylable objects
    • TidyStyle – storage class for a style
  • TidyScrollable – base interface for scrollable actors
    • TidyAdjustment – object for clamping a value between two boundaries (with quantum increments support)
    • TidyScrollBar – scroll bar actor controlling an adjustment
    • TidyViewport – scrollable viewport controlled by a pair of adjustments

Update@2008-02-07T10:01Z: after this announcement, Chris added two new actors:

  • TidyScrollView – a viewport with scoll bars
  • TidyFingerScroll – a viewport with kinetic scrolling

Plus a lot of bug fixes.

there are examples for basically every class and functionality under the tests/ directory.

since everybody want screencasts these days:

this is still in the prototyping stage; meaning: if it breaks (and it will break) you get to keep both the pieces. also, there are rough edges and missing functionality. we’ll keep working on it and adding new classes between now and Clutter 0.6 (and after), and also use Tidy as a testing ground for Clutter functionality and staging ground for actors/data structures/interfaces.

you can check out Tidy from SVN using:

  svn co tidy

or browse the repository from your web browser via: (raw) (viewcvs)

in other, Clutter-related news:

  • Iain has been working on a Clutter and WebKit-based browser actor; you’ll find a very cool screencast of it on Iain’s blog.
  • In Clutter trunk we landed initial support for FBOs and we’re fixing bugs/updating bindings/updating documentation toward the 0.6.0 release.
  • It’s a bit old, but I’ve been updating the Vala bindings for Clutter and Clutter-GTK, so you can now use all the bling with Vala; you’ll need Vala trunk, but it’s worth it.

Kingdom of Spain

Clutter: Today I released the first developers snapshot of Clutter 0.6 – Clutter 0.5.0. The full announcement is on the Clutter blog, and since it’s very long, I won’t copy and paste it here. You can grab 0.5.0 here; as usual, this is a unstable snapshot, and it’s meant to be used to play with the new API, start binding it and find the inevitable bugs that might have creeped in – and help us fixing them as well. :-)

Last week I also went through the huge list of changes, additions and removals in the public API; the result is a collection of seven emails (1, 2, 3, 4, 5, 6 and 7) I sent on the clutter-list – complete of mistakes which I can only attribute to the amount of food, wine and beer I had during the Xmas break.

I’m incredibly proud of how much Clutter grew since the 0.4 release we did after GUADEC; the amount of bug fixes alone makes it worth to check it out – and the new features list is impressive. A lot happened, and a lot more will happen in the near future; some things are already here – but will be announced in due time.

As always, kudos to everyone that has helped by filing bugs and patches; started writing bindings; and last, but not least, contributed documentation.

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 repository ((As usual, at 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.

Rome Wasn’t Built in a Day

People often arrive on the #clutter channel ((IRC: – join today!)) with troubles building Clutter from SVN: dependencies, installation in non-common prefixes, etc.

Luckily, GNOME has Jhbuild, which is easy to set up ((the wiki page linked has it running in less than ten easy steps)) 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 help ((be sure to specify which distribution you have)).

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!


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 read ((obviously nothing prevents adding an XML parser, and use both)). 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.