clutter 1.8 — last Friday I rolled the first release of the new stable 1.8 cycle, and Rob rolled the first stable release of the now standalone Cogl. it’s been six months of intense development, with lots of contributions, and I’d like to thank everyone who submitted patches, opened bugs, added a translation, or even dropped by in the #clutter IRC channel to tell us that they were using Clutter for their awesome project.

clutter 1.9 — instead of resting after pushing 1.8 out of the door, we’re already hard at work on what will become 1.10 in six months. while Cogl is getting more and more refactoring to make the code base more understandable and reliable, as well as preparing the way for new features, Clutter is also getting some refactoring. today, for instance, I worked on building Clutter with multiple backends in the same shared object. one of my first major contributions to Clutter, back in the OpenedHand days, was to provide the ability to have multiple backends — and it worked pretty well: after the GLX backend we got a Windows backend, then a framebuffer backend, then an OS X backend. during the years, the implementation was amended here and there to avoid leaking the backend implementation all over the place, and we always resisted the temptation (and the outside pressure) to provide a full abstraction library for the windowing system akin to GDK. this allowed us to maintain the backend code lean and lightweight, to the point that it took me literally an hour this morning to go from the current HEAD of master to a test running with either GDK or GLX (depending on an environment variable) — and most of my changes were in the build system, not in the code.

as an example, this is a simple test program that checks the backend support at both compile and run time; using Clutter from the multi-backend branch, compiled with --enable-x11 and --enable-gdk, you can run the example on X11 using:

$ CLUTTER_BACKEND=x11 ./test-backend &
$ CLUTTER_BACKEND=gdk ./test-backend &

multiple backends, same great taste

and have two instances, one using the native X11 backend and the other using the GDK backend.

there’s still some work to do, namely fixing Clutter-GTK to work with a multi-backend Clutter, and making it use the GDK backend by default, if found. there’s also the issue of being able to use the GLX_EXT_texture_from_pixmap extension under the GDK backend on X11, if available, so that we can efficiently embed GTK widgets rendered off-screen like we can already do when using the Clutter X11 backend.

all in all, this work will help towards the goal of using Clutter and GTK together in a more organic fashion, and with fewer blocks and hacks in the middle.

Have You Seen This Gnome?

who was apparently reported as missing in action.

let’s see if we can find a new home for it…

I have a talk on Saturday at 11:20, and I’ll have the Board meetings contending for my presentation, hacking and meeting time during most of the conference — but every minute I can spare I’ll be available for chatting about Gnome, Gnome OS, GTK+, and Clutter.

by the way, make sure to attend the talk that Damien, Neil and Chris will present right after mine — it’s going to be awesome.

see you in Berlin!

• box it inside a GValue
• call the set_property implementation of your class
• unbox the GValue
• call the public setter function
• set the value inside the private data structure
• free the GValue

there are at least two unnecessary steps, there: the boxing inside GValue should only be necessary for transformation purposes — i.e. taking a GValue and running the transformation function from the passed value type to the property type — but that path should not be taken for variadic arguments functions like g_object_set() since the type used to read the value from the va_list is the property type itself and no transformation is necessary or possble; and calling the set_property() implementation, which is just a huge switch on the property id used when installing the property on a class, just to then call the public accessors. now, try modifying five or so properties at the same time on a hundred objects at 60 frames per second. you can probably get away with it — but only just.

last year, Rob Staudinger proposed some code that provided property access through both accessor functions and direct structure member access through field offset. sadly, I felt that his API was still repeating the same issues of the GParamSpec API: constructors with different signatures (try remembering the arguments and their order between integer properties, enumeration properties, string and boxed properties); reliance on a big switch inside the class implementation; and a general lack of integration with GObject itself.

the last point is mostly what interested me; GParamSpec is meant to be used as a validation tool for a value; it describes the constraints, the default, the prerequisite type, etc.. it’s used to describe properties, but that’s almost a side-effect — a GParamSpec can exist in a vacuum, and can be used regardless of GObject itself. if we wanted to access an object property, the object class should be far more involved in this. we should be able to tie the property description to the structure field that backs it in the implementation; we should be able to define the functions that access it; and we should be able to even provide a default implementation of these accessor functions without requiring developers to actually write them.

another issue with the current state of affairs with GObject properties is the amount of code you have to write. let’s look at a simple class mapping a bunch of fields to properties. right now, you’d have to write every single accessor pair, with hand-written validation; you’d have to hard-code the defaults in three places (the GParamSpec, the instance init function and the accessors); and you’d have to write the set_property() and the get_property() implementation, which end up calling the public accessors anyway because you want to do validation and notification of changes in one place only.

almost all of this code could be autogenerated, even through the C pre-processor.

so, to make a long story short, during the past couple of weeks I started fleshing out the implementation of a new property API for GObject — GProperty.

GProperty is still based on GParamSpec, but it hides all the nasty so you only get a bunch of constructors with the same signature (no more trips to devhelp to check out the <code>g_param_spec_enum()</code> order of arguments) and a generic API for setting constraints like ranges, default values and prerequisite types. plus, you get to specify the field and/or the accessor functions:

  test_object_property[PROP_FOO] =
    g_int8_property_new ("foo", G_PROPERTY_READWRITE,
                         G_STRUCT_OFFSET (TestObjectPrivate, foo),
                         NULL, /* setter */
                         NULL  /* getter */);

  test_object_property[PROP_BAR] =
    g_float_property_new ("bar", G_PROPERTY_READWRITE,
                          -1,
                          test_object_set_bar,
                          test_object_get_bar);

  g_object_class_install_properties (object_class,
                                     G_N_ELEMENTS (test_object_property),
                                     test_object_property);

there are a bunch of other features (automatic atomic properties, macros for auto-generating accessors, per-class default value overriding) for which I’ll just point you again to the bug and the GLib branch; today, though, I wanted to verify whether one of the reasons for working on this — making generic property access faster — actually benefited from these changes. it turns out that it really does: calling g_object_set() in a tight loop with simple values (integers and floating point) improved from the equivalent, GParamSpec-based classic implementation by 2.10x on my Core 2 Duo; if you throw a string into the mix, the improvement is by 1.5x. my initial ballpark figures were way smaller, so I was pleasantly surprised.

hopefully, this work will get more eyeballs during this cycle — and it’ll land in time for 2.32 (and Gnome 3.2).

congratulations to everyone who contributed — feature, widget, application, translation, one-liner, documentation, art, design. you all rock my world.

today I’m immensely proud to be a GNOME developer and user.

gnome-utils: after years of neglect, and due to a spectacular sugar rush on Saturday, I took again a look at gnome-utils — and in an afternoon I ported the Dictionary to both GSettings and GtkApplication. the APIs are a breeze to use, and the amount of crappy code I wrote years ago before getting a bigger clue about GObject and GTK+ development has been reduced. kudos Ryan, and everyone else who worked on GSettings and G(tk)Application. depending on time constraints, either I or Cosimo (maintainer extraordinaire) will do a release today.

clutter: a bit earlier than expected, but today I just spun the first release of the stable cycle — 1.6.0. I’ll send you to the announcement on the Clutter blog for details — but I wanted to copy the “thanks” section on this blog, in order to give these people a token of my appreciation for their work in making this the best Clutter release as of yet:

Robert Bragg, Neil Roberts, Damien Lespiau, Elliot Smith, Chris Lord, Owen W. Taylor, Bastian Winkler, Tomeu Vizoso, Kristian Høgsberg, nobled, Lucas Rocha, Ole André Vadla Ravnås, Adel Gadllah, Alexandre Quessy, Andika Triwidada, Johan Bilien, Jussi Kukkonen, Piotr Drąg, Alejandro Piñeiro, Aron Xu, Colin Walters, Evan Nemerson, Giovanni Campagna, Maxim Ermilov, Mike Owens, Nguyễn Thái Ngọc Duy, Ray Strode, Rob Bradford, Roland Peffer, Stephen Kennedy, Viatcheslav Gachkaylo, muflone.

these guys rock my world, and if you use Clutter then they rock your world as well. so if you meet any of them, make sure you offer them a beer or a beverage of choice.

don’t use a GTimeVal, and above all: don’t even think about adding a GType for GTimeVal inside your own project.

first of all, because all that you can do with GTimeVal you can also do it with an int64; second of all, because if everyone starts defining boxed types for types in GLib, we’ll soon start to get collisions. and, no: adding a boxed type in GLib is not a good idea — see above, re: int64.

if you need second resolution (which is fine for most operations), just use tv.tv_sec; if you need millisecond resolution (which is fine for file operations), just use:

  gint64 msecs = tv.tv_sec * 1000 + tv.tv_usec / 1000;

and if you need microsecond resolution (which is fine if you’re bordering insanity), then use:

  gint64 usecs = tv.tv_sec * G_USEC_PER_SEC + tv.tv_usec;

this blog post has been brought to you by your friendly neighbour GObject and language binding developer.

the patch that was submitted was the incorrect one; I’ve been fixing the implementation since then, mostly because the API is correct — and went through different eyeballs to ensure that — and we wanted to land it before the GLib freeze. the implementation, alas, has issues — and not just the ones you saw.

as I said, it’s definitely my fault: I reviewed the original in a way that was less than acceptable. I sincerely apologize for that.

okay, having said that, and resuming my usual self: bitching on planet GNOME is not going to get anything fixed. insulting the maintainer when the issue lies mostly in a “patch lieutenant” (such as myself) is also not how polite people deal with errors.

finally, saying that the code needs to be taken out back is a lame cop-out and it is an untenable position for anyone contributing. the code went in, there were issues, so it needs to be fixed. if we waited for perfect code the amount of merged we’d get would be zero. that code has been in the bug for the past 6 months, and it’s been discussed in the past IRC meetings, with public minutes and logs.

so, please: file bugs. I’ll try to close them faster than you can open them.