I am the man that arranges the blocks
Clutter 0.4.0 was, finally, released two days ago. Not only the core and add-on libraries but also the language bindings are available for this new stable release cycle.
We already started working on trunk for the 0.5/0.6 development cycle, which should hopefully lead up to another stable release in six months; there already is a nice list of features we are working on, but I’d like to see more requests, more patches ( ;-) ) and people working on even more language bindings.
Lately, people have been trying Clutter, and reported bugs and misbehaviours. When asked what revision they were using, it turned out that they did a checkout from Clutter-core trunk. I made this point on the mailing list already, but I’ll just blog it so that it doesn’t get lost (until we have set up some web archives for the list): Clutter trunk is meant to break basically with each commit – so you should checkout trunk only if you want to help developing Clutter. If you want to use Clutter from SVN, check out the clutter-0-2 branch. Each stable release of Clutter (0.2, the next 0.4, etc) is guaranteed to be ABI and API compatible within the same minor release; until we reach 1.0, we’ll also keep providing support for parallel installations, so that you can target a specific minor revision without breaking.
So, if you want to try out Clutter, use the stable branch – and remember to file bugs against that.
A couple of weeks ago I decided to give git a try, after this old post written by nud about using git-svn to create a bridge between a project stored under a SVN repository and a git repository.
I’ve choosen Clutter mostly for these reasons:
I fired in my terminal the git-svn commands and less than ten minutes later I had a fully working git repository for Clutter, complete with history. What I liked from the very beginning were the lightweight branches git employs; you can have multiple branches inside the same work directory and you can switch between them with a single command. Actually, I found that having a single branch for each one of the changes and then merging them back into the main work branch is an incredibly natural way of dealing with the development of a project; it’s like having a locally distributed approach – which git makes it easier to adopt than, say, bazaar; the git-web interface is also really sweet, and much more useful than viewcvs alone (and, in many cases, of the viewcvs+bonsai coupling); finally, the speed factor is huge: each command, except for the cloning of a repository (which is something you end up doing just once anyway) is almost immediate.
After a bit more than six months of work, Clutter 0.2.0 is finally out!
We put a lot of effort in making the API a bit less rough around the edges, and adding new features at the same time. Like the new Behaviour objects which can be used to control multiple actors using a function of time; or the fixed point API, which should make Clutter work fast even on embedded devices; or the Pango integration, which should keep the texture memory usage low and give you all the features of pango. On top of that, there’s the new memory management semantic of the actors – now working like GTK+ widgets: now you just ave to add an actor to a group, and the group itself will be responsible of deallocating the memory when the group gets destroyed.
Along with the core library there’s a GStreamer integration library, which you can use to add audio and video support to a Clutter application; a Cairo integration library, for drawing directly on a Clutter texture actor; and, obviously, Perl and Python bindings, so that you don’t have to use C to use Clutter.
Clutter is still a work in progress, and we at OpenedHand hope to add even more new features in the 0.3 development cycle – some of them are already planned and in the works right now. What we need are application developers willing to use Clutter and telling us what we need to add to Clutter to make it rock even more.
Dear LazyWeb:
I’m trying to clean up the python bindings for the next release of a GObject-based library, so I’m using pygtk and its codegen magic; unfortunately, being codegen.py an incredibly bad program, I can’t see why or how it’s failing to read the .defs and .override files, and why it doesn’t generate anything. Is there a way to have some sort of error message or information except for the quite useless statistics recap? I’m using the same build system used by pygtk, so this must work if you apply enough bad mojo somewhere. I don’t want to dwelve into the 1707 lines of dense python – I’d rather spend my time binding a library.
Thanks.
Three hours, and many curses, later: it seems that I have mistakenly deleted a '%%' between a ‘ignore-blob’ declaration and the body of the override file. This, for posterity, is logically equivalent to “ignore whatever exists after this space”. which is, all in all, logically coherent, and I’m more than willing to beat my head against the wall for my stupidity. But if codegen.py had a “verbose” mode (instead of me sprinkling the code with “print” statements) I would have found this way sooner than the three hours it took me. A simple line redirected to stderr telling me “hey, I’m ignoring this and that” would have been sufficient.
gtk-recent: For those who missed the mail on gtk-devel-list, language-bindings and desktop-devel:
Unfortunately, when importing the GtkRecent API in GTK+ I made a mistake and these two functions have been erroneously left inside the GtkRecentChooser interface API:
gtk_recent_chooser_set_show_numbers() gtk_recent_chooser_get_show_numbers()These two functions try to set the “show-numbers” property, which is installed only by GtkRecentChooserMenu and it’s not one of the properties defined by the GtkRecentChooser interface. Using these functions on a GtkRecentChooserMenu (or any other custom GtkRecentChooser implementation which defines a boolean “show-numbers” property) will yield the expected results, while using them on a GtkRecentChooser implementation that does not support the “show-numbers” property will result in a warning.
Since we are in a stable release we can’t mark those functions as deprecated, and we cannot remove them without breaking the API. You are advised not to use these functions: use the GtkRecentChooserMenu functions instead:
gtk_recent_chooser_menu_set_show_numbers() gtk_recent_chooser_menu_get_show_numbers()Language binding authors should not bind those functions, but bind the GtkRecentChooserMenu functions instead.
These functions will be marked as deprecated as soon as GTK+ will branch off for the 2.11/2.12 cycle, so you’ll have to bear with this inconsistency for a short period of time.
language-bindings/1: By the way, gtk2-perl now supports the GtkRecent code in HEAD, thanks to the hard work of Torsten kaffee Schoenfeld who fixed most of my first iteration binding code and wrote the tests for it.
language-bindings/2: I also finished the Perl bindings for Clutter, as well as the Python ones. As I changed Clutter to behave like GTK, with the ClutterActor objects being created with a “floating” reference count, you’ll have to update Clutter to HEAD if you want to test the bindings. Beware that Clutter’s API is still a bit fuzzy at the moment. Of course, if you find bugs in the library or in the bindings, be sure to report them.
Now Listening: Last-exit, Neighbour radio