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¹ to do this would be keeping the 3.0.0 in alpha state, call it 2.99.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 #gtk-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

1. kudos to iain [↩]
2. but install a pkg-config file called gtk+-3.0 and install the headers under gtk-3.0 [↩]

gtk+: the gtk+ team meeting on tuesday went really well — and part of the discussion was incorporated in Kris always excellent State of the union talk. the team went over and over this issue since last GUADEC and during the hackfest, and even though something at some point will probably go wrong the plan is good and allows leeway to reduce the overall effort for moving the entire platform. I think that given the circumstances this is the best plan that can be realistically implemented.

gnome: everyone will be discussing the release team plan as well. I can only say: let’s do it!

clutter: the Clutter Guts talk went really smoothly; we tried to fill Matthew shoes — and had to be in three to do it — but I think people came out of the talk with more knowledge about the deep magic and the pixie fairies dust that power Clutter and make it as awesome as it is. as I said during the talk, Clutter 0.8 is really in the final stages now, and it’s going to be released as soon as we finish testing some of the backends. people will just have to wait a little bit, but by the time everyone gets back home from GUADEC they will be able to get the tarball from the server.

finally arrived at Istanbul with the rest of the OH gang. it has been quite a trip, with a massive delay at Heathrow caused by bad weather¹. we landed around 2am local time and went straight to the hotel. hopefully, I’ll be able to wake up at a reasonable time and not feel rubbish the whole day.

see you around.

1. I know, I know: shocker [↩]

givin u talk

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.

if you’re not even able to make decent drivers for your own (admittedly crappy) graphic hardware, please have the decency to fail and go out of business as you rightfully deserve.

No love,
  Emmanuele.

The second release is - finally - 2.17.0, the first release of the new unstable release cycle which will lead to gnome-utils 2.18.0.

The major change in this release is in Baobab, which acquired the new, spiffy, cairo-based ringchart view, thanks to the hard work of Fabio, Paolo, Alejandro and Miguel. Baobab also dropped the search option, which mostly replicated the Search Tool already included in gnome-utils. Baobab user interface was cleaned up, its memory consumption was reduced and many bugs were fixed.

The other modules in gnome-utils got some love, but not much; my development tree still doesn’t build well and it’s not ready for inclusion in HEAD, but I plan to work on it before the next release.

As usual, download, test and file bugs.

The wedding went incredibly well: the ceremony itself was so short (twenty minutes) that I don’t remember much of it.

We were married in a beautiful building in Milan, with frescoes made by Tiepolo, by a city hall official.

The lunch was much more fun, even though it proved to be really tiresome: we went to sleep at 18:00 and woke up at 9 the day after.

We were cheered by (many) relatives and (many) friends - surely one of the best days in my entire life, and an awesome way to begin a new life as well.

More photos: here

Now Listening: The Decemberists, Picaresque

Wil writes gorgeously. I found myself smiling, grinning or plain laughing out loud while reading it. As a trekker, and a geek, I can’t but relate to the stories he wrote; I really can’t wait for Just a Geek to arrive (Marta bought me that too).

[books]
[wil+wheaton]

[doom]
[doom+video+billgates]

hacking: after moving the RecentManager to new new BookmarkFile parser/writer object, I resumed working on the actual separation of the recently used resources viewer widgets (implementing the RecentChooser interface) and the list controller (the RecentManager object). Last week I removed every trace of sorting and limit handling code involving the manager object from the widgets, and recoded them directely into the widgets themselves. Thus, it’s now possible to have a single manager instance and multiple viewers bound to it, instead of creating a manager object per widget:

Two widgets, one manager

Sorting, filtering and the list limit property are still present in the RecentManager object; this way you could have a custom sorting and filtering functions set into a manager, and then multiple views attached to it.

Separation was a job the the current EggRecentModel/EggRecentView objects didn’t handle well enough; basically, you could feed you own model to a EggRecentViewGtk widget, but every other widget using the same model would display the same data, with the same sorting, filtering and list size. This behaviour doesn’t really match the MVC paradigm; for instance, using the same TreeModel you could set up many TreeView widgets, each of them showing only some part of the data stored in the model. Filtering, sorting and size are handled by the TreeView code, not by the model.

The same should happen with the recently used resources list; also because this could lead to the creation of a default singleton instance of the manager object, in order to reduce memory and locking issues due to the on disk storage.