Good for the Soul

today was Free Comic Book Day and Marta and I decided to go to a comic book store and get some new additions to the ever-growing collection we have at home. we opted for Gosh as we read a week ago that none others than Alan Moore and Kevin O’Neill would be there to sign the first chapter of the new League of Extraordinary Gentlemen installment.

Lego Action Comics #1, by levork — licensed under CC BY-SA

we arrived, admittedly late, but we were absolutely unprepared for the insane queue that was already in place: it went around the entire building. we tried to stay in the queue for some time, but it was clear that we would have had to wait for at least two or three hours in order to get in. albeit very sadly, we decided to get in the store and abandon the quest — drowning the disappointment in sane consumerism.

we got:

  • The League of Extraordinary Gentlemen, volume III: 1910
  • Batman: The Long Halloween, by Jeph Loeb and Tim Sale — recommended to all who liked The Dark Knight movie and in general to all the Caped Crusader’s fans
  • 1602, by Neil Gaiman — I only had this in italian but Gaiman’s writing should not be translated
  • Embroideries, by Marjane Satrapi
  • Blankets, by Craig Thompson

all in all, not much of a free but a great comic books day.

My dear Evolution,

please, please stop the utter madness of not showing email addresses in the to: and cc: fields if they match an entry in the addressbook.

I’m writing an email. therefore it is safe to assume I know what an email address is. you don’t have to shield me from the existence of email addresses, especially if this prevents me from checking that the email I’m sending is effectively directed to the people I intend to, and not to what your brain damaged autocompletion decides to fart in my text entries.

no love,
  Emmanuele.

Dream About Flying

as usual — long time, no blog.

my only excuse is that I was busy with other things: new job, new office, holidays… you know, whatever happens between coding. :-)

it’s that time of year again, and we’re nearing another Clutter release — this time it’s a special one, though, as it is 1.0.0. which also means that the API will be frozen for the entire duration of the 1.x branch: only additions and deprecations will be allowed ((no worries about stagnation, though — we are already planning for 2.0, even though it’ll take at least a couple of years to get there)).

since we’re in the process of finalizing the 1.0 API I thought about writing something about what changed, what was added and what has been removed for good.

let’s start with the Effects API. the Effects were meant to provide a high level API for simple, fire-and-forget animations ((even though people always tried to find new ways to abuse the term “fire-and-forget”)). they were sub-obtimal in the memory management — you had to keep around the EffectTemplate, the effects copied the timelines — and they weren’t extensible — writing your own effect would have been impossible without reimplementing the whole machinery. after the experiments done by Øyvind and myself, and after looking at what the high-level languages provided, I implemented a new implicit animation API — all based around a single object, with the most automagic memory management possible:

  /* resize the actor in 250 milliseconds using a cubic easing
   * and attach a callback at the end of the animation
   */
  ClutterAnimation *animation =
    clutter_actor_animate (actor, 250, CLUTTER_EASE_IN_CUBIC,
                           "width", 200,
                           "height", 200,
                           "color", &new_color,
                           NULL);
  g_signal_connect (animation, "completed",
                    G_CALLBACK (on_animation_complete),
                    NULL);

this should make a lot of people happy. the easing modes in particular are the same shared among various animation framworks, like tweener and jQuery.

what might make some people slightly less happy is the big API churn that removed both ClutterLabel and ClutterEntry and added ClutterText. the trade-off, though, is clearly in favour of ClutterText, as this is a base class for both editable and non-editable text displays; it supports pointer and keyboard selection, and multi-line as well as single-line editing.

another big changed happened on the low level COGL API, with the introduction of vertex buffers — which allow you to efficiently store arrays of vertex attributes; and, more importantly, with the introduction of the Materials which decouple the drawing operations with the fill operations. it also adds support for multi-texturing, colors and other GL features — on both GL and GLES.

Gradients with Clutter

after unifying Label and Entry, we also decided to unify BehaviourPath and BehaviourBspline; after that we added support for creating paths using SVG-like descriptions and for “replaying” a Path on a cairo_t. well, the Cairo integration is also another feature — clutter-cairo has been deprecated and its functionality moved inside ClutterCairoTexture.

one of the last minute additions has been ClutterClone, an efficient way to clone generic actors without using FBOs — which also supercedes the CloneTexture actor.

the Pango integration has been extended, and the internal Pango API exposed and officially supported — now you can display text using the Pango renderer and glyphs cache inside your own custom actors without using internal/unstable API.

thanks to Johan Dahlin and Owen Taylor, Clutter now generates GObject-Introspection data at compile time, so that runtime language bindings will be ready as soon as 1.0.0 hits the internets.

finally, there’s a ton of bug fixes in how we use GL, how we render text, how we relayout actors, etc.

hope you’ll have fun with Clutter!

Paint the Silence/3: Gran Finale

the third and final installment of the ongoing saga

thanks to Damien, I finally found a way to shut up libtool and get a clean output for the build of a project: shave.

Clutter is the first project using it, and I already easily caught compiler warnings ((even without using the anal-retentive compiler flags and -Werror)) because my terminal is not full of crappy, four lines long incantations ((and even though I’m not an autotools ninja, at least I read the documentation and not just blindly copy stuff from various projects in the hope they work; so the autotools setup in Clutter is pretty much well tested so that I don’t need to worry that files get installed in a different location than expected)).

big kudos to Damien!

Last Ride In

last night I could not sleep, so I decided to upgrade my old WordPress 2.0.11 (yes, you read that right — 2.0.11) installation to the New! And! Improved! hotness of WP 2.7. unfortunately, something went very wrong in the conversion process and all I got was a lousy 301 – Permanently Moved every time I tried to access the main page. the admin pages worked fine — I could even write, edit and export posts; nevertheless, nobody could view them.

so I decided I was tired of handling stuff on my own, and keeping it working and up to date.

GNOME already has a blogging platform, and I use my blog to talk about GNOME-y stuff anyway — so presto: here’s my new blog, on blogs.gnome.org.

I’m trying to import the old posts here, using the WXR file that my 2.7 exported, but apparently there’s a small mismatch in the Import admin page: it says that it can load up to 8 megs files, but then it chockes with a 1.9 megs one, and it tells me that 1.5 megs are the limit. I’ll trim down the XML and see what happens.

later: WPmu imported the WXR just fine as soon as I removed some of the spam-labelled comments and trackbacks (which shouldn’t have been exported in the first place, if I may add). it did even ask me to import the attachments from their previous location. in one word: awesome!

All the Old Showstoppers

okay, new rule ((apologies to Bill Maher)): it’s okay to install a GObject property like this:

pspec = g_param_spec_string ("title",
			     "Title",
			     "The title of the item",
			     NULL,
			     G_PARAM_READWRITE);
g_object_class_install_property (gobject_class, PROP_TITLE, pspec);

instead of the usual way you see in other GObject-based libraries, where we l33t h4x0rs dispense from the use of an explicit GParamSpec variable. this is especially true if you are trapped in 1983 and are still using an ANSI 80×25 terminal — though you should probably know that here, in 2008, 100+ columns are safe.

oh, and fill out the name and blurb fields of the property: GObject provides a little bit of introspection, but if you willfully ignore it then we can just forget about stuff like the GObject-Introspection project.

please, every time you install a property using a line like this:

g_object_class_install_property (
	gobject_class, PROP_TITLE,
	g_param_spec_string ("title", NULL, NULL, NULL,
	                     G_PARAM_READABLE | G_PARAM_WRITABLE));

an unfortunate incident will involve a bucket of puppies and a belt sander.

comments saying “gobject sucks you should be using ${ZEALOTS_OWN}” will be deleted without mercy because they miss the point by a hundred and fortyseven miles

In the Mood

well, I failed at blagging each day of the User Experience hackfest, but mostly because of the sheer amount of discussions, designs and work done.

during the first common session on monday we all decided to split off into four groups:

  • file management
  • window and application management
  • widgets/gadgets/applets
  • effects and animations

I decided to work on effects and animations, along with Eve, Neil, Matthew and Andreas ((who’s totally getting married — just as vuntz is expecting a baby)). the wiki page of our group lists most of the stuff that came up in the group discussions and brain storming ((or idea showering)). when not in the effects and animations group I was hanging around with the window and application management guys. since Tomas, Robert and Matthew have been working on a Clutter-based compositor for Metacity, I decided to give it a spin and work on some of the “animation tenets” that came up during the hackfest — like showing the direction of the workspace switching and provide a visual cue to the user that the windows are not going away forever, and are just being moved in another area of the screen. I know that Compiz is probably going to have these kind of effects some ten levels deep in the configuration manager, but the configuration UI always makes me want to carve my eyes out with a melon spoon while being bludgeoned to death, and the defaults are usually so bad that I develop seasickness after 15 minutes of continuous use — hence, the usage of the Clutter-powered Metacity.

the other groups did an awesome job as well: a lot of the ideas floating around will require hard work and time in order to be implemented, but they all contain a refreshing view of the desktop and challenge some of the fundamental tenets of the user interaction, based on the feedback from users and designers — and especially without resorting to something completely new or alien that will require years to get right for developers and to adjust the workflow for users, or just announcing new frameworks with the usual jingoistic tones common to open and closed software projects alike.

Flying Teapot

final checks and the usual ohmygodwhycan’tIfindanything mode before I take the flight to Boston for the User Experience hackfest organized by Owen, Federico and Vincent. Neil and I will be talking about Clutter, what it does, and what it can do to enhance the user experience on a modern desktop.

then, it’s Boston Summit time! it’s going to be my first summit, but given the past editions and the people attending I just know it’s going to be awesome.

see you in Boston!

Stuck with me

guadec 2008: I’m late, but I wanted to thank everyone in the GUADEC team for making this edition of the conference really rocking. thanks to everyone.

clutter: well, after the 0.8.0 release during GUADEC things have slowed down — but just a little bit; we’re fixing bugs in trunk and preparing for a 0.8.2 release of Clutter core. we also released the various integration libraries, and I’m trying to find more time to fix up the bindings. at the moment, the only bindings that have been officially released are the Perl bindings, the C++ bindings (thanks to Murray Cumming), the C# bindings (thanks to Thomas Machelen) and the Ruby bindings (thanks to Neil Roberts). I plan to release the Vala bindings really soon now — just some finishing touches to make the API nicer to use.

pyclutter: I wrote a couple of weeks ago that the Python bindings for Clutter have been, let’s say, problematic. taking a week or so away from them seems to have worked well enough, though, and now trunk is in a much better shape. unfortunately that have been some reports of segfaults and weird memory allocation issues — so any help in terms of testing is much, much appreciated. I also finally got around and generated the API reference for pyclutter using a slightly modified script coming from pygobject — but the content is missing sections like the object properties and signals. it just needs editing and some kind Python developer to start contributing documentation and fixes. again: any help is much appreciated.

travel: next week I’m headed to Sunnyvale for work; I’ll be there from the 17th to the 22nd. after I get back I’ll finally get a couple of weeks off, which I’ll spend with my wife travelling between New Haven and New York.

gnome-utils: finally found some time to do bug triaging and applying some old patches. nothing stellar: for what I have in mind I’d need a lot more time, or a lot more contributions (and less drive-by patches). for instance:

  • gnome-screenshot needs a maintainer, badly. preferably somebody with a dual screen set-up, that can test the behaviour on multiple screens;
  • gnome-system-log either needs a rewrite and a maintainer or needs to be dropped from gnome-utils and moved into its own module and its presence in the desktop suite re-evaluated; as it is, it’s mostly a liability and a relic of the past; if somebody comes up with a maintained replacement, we can talk about integrating that;
  • gfloppy needs to go. seriously: it’s useless. I had hopes for gnome-format, but now David Zeuthen is planning for a complete disk manager using the DeviceKit-disks API and PolicyKit so we can either wait for that, or write something really simple using those two APIs.

as you can see, gnome-utils is not at all dead — it just lacks manpower sticking around enough to get a SVN account and an entry in the MAINTAINERS file.

When the World Ends

I’m delaying my sleep time further on, after two hours on IRC discussing the gtk+ 3.x issues spawned by Miguel’s blog post, because there are a few points I’d like to make.

discussion: the first, and foremost, is: let’s not use blogs to discuss. blogs suck at this — they break down communication, they are slow and they are not meant to do this kind of stuff. we have meetings, mailing lists, IRC — all of these are better versed at discussing things. for instance, I would have loved to have Miguel at the gtk+ team meeting of tuesday at GUADEC: it would have been a great discussion, I’m sure of it, and we might have had a different state of the union talk.

marketing: let’s be honest, here — we’ve been joking a lot on KDE 4.x and their marketing trainwreck, and how it was similar to the GNOME 2.0 own marketing trainwreck. there’s a difference, though, with gtk+ 3.0 and it is: gtk+ is a library, is not an entire desktop; if we call 3.0 the initial release of the 3.x API series it’s because we promised that the 2.x API series would not break API nor ABI. QT 4.0 was released with KDE 3.5 still going strong and KDE 4 far away in design land, and the features that are now used by KDE 4.x have been added during the 4.3 and 4.4 releases of the QT platform.

features: yes, 3.0.0 might not have features. is this bad marketing? probably. so we need to fix this. a way ((kudos to iain)) to do this would be keeping the 3.0.0 in alpha state, call it 2.99.0 ((but install a pkg-config file called gtk+-3.0 and install the headers under gtk-3.0)) and add features to that until we get to a 3.0.0 that developers will want to migrate to, like the new scenegraph API or the new style API. let’s break with 2.x in style. :-)

communication: there’s a certain lack of communication between the gtk+ team and the users of the library. in my opinion, it’s due to the small number of active developers and to the fact that ISVs don’t really get involved into shaping the platform they are using. they have the source code, and sometimes it’s easier to fix in-house than to communicate and go through the proper process — and this is a structural problem that is caused by the small number of people involved in the said process as well. the gtk+ team needs to open up more, and at the same time the ISVs need to get more involved. sometimes it feels to me that the team is waiting for features, direction and help in the development, while the users of the library are waiting for the team to come up with the perfect plan to fix all the bugs and warts while retaining the whole API and ABI.

process: this is connected to the first point — we have a lot of channels, and it might be daunting to actually follow them all; but we’re also open in terms of discussion and revision. this is our strength. so please: if you want to discuss, join the IRC meetings on the -devel channel on Tuesday at 20:00 UTC or send an email to gtk-devel-list with your points. get involved. help shaping the future. don’t stand idly by, and wait for stuff to break to complain.

I’d like to thank iain, Hallski and campd for the interesting discussion — and for the points raised and taken