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

Something on my back

dear, all-knowing and all-powerful lazyweb;

what’s the reason why python segfaults ((yes, python segfaults — and it does inside pygobject)) with this error message:

TypeError: Cannot create a consistent method resolution
order (MRO) for bases Container, Scriptable

when I’m trying to instantiate a python class inheriting from a C class that implements those two interfaces? just for the record:

  • the interfaces have no colliding methods
  • the python class is registering a GObject type
  • the python class has no colliding method with either interfaces

I can point at the code or, if python-gobject/gtk maintainers are at GUADEC, I can show them right away. you can easily find me: I’m the one swearing at python.


so, it turns out that the plans of releasing Clutter 0.8 right after GUADEC were a little bit on the conservative side, since

thanks to all the contributors for bugs opened, patches written, tests performed — you all rock my world.

now you’ll just have to wait a tiiiiny little bit for the integration libraries ((they all work with the new API, they just need to be distchecked)), for the bindings ((this will take some more time but they’ll be there)) and for Tidy ((will demo something tomorrow at my lightning talk around 14:30 if you’re at GUADEC)).


this GUADEC has been quite a ride, and we’re just halfway through.

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.


the song from the Decemberists, not the city

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 ((I know, I know: shocker)). 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. :-)