Posts

Once upon a time, threeintrepidindividuals made Empathy publish your location to your contacts, and show your contacts’ locations on a map. Today, I noticed that the Location tab is missing from Preferences—I guess Debian’s Empathy is built without GeoClue support for some reason—and as a result the map looks rather forlorn, what with none of my contacts publishing their location:

A map is an obvious demo to build, but I don’t think it’s that useful (even when it had more than zero contacts on it, I never looked at it).1 So what would be more useful? For starters, here’s some “relevant art” from Skype, showing a contact’s local time in their tooltip:

Adding that to Empathy might be a useful first step. But unlike Skype, it’s possible to use this information outside the IM app. So, if I spend a lot of time chatting to friends in Melbourne and New York, why not automatically add those timezones to GNOME Clocks? (The last two mock-ups in that section look particularly bare—perhaps the names of some contacts could show up in the space where “local time” does for Boston.)

For this to be useful, of course, someone would have to fix the publishing of location information in the first place. But if fixing it produced a more compelling feature than a map, it would not be such a thankless task.

Top designers agree! To quote Allan Day, “I could live without contacts on a map ;)”. [↩]

I started using these as a Darcs refugee, but they’re also a good way to avoid doing git add -p && git commit -a through overly-active muscle memory. I could probably simplify them to use git commit -p.

I have a lot of IM accounts1. I often want to turn groups of them on and off: for instance, when I’m not at work I turn off my Collabora accounts, and when testing IM-related stuff I need to turn on my test accounts. I got bored of finding the Messaging and VoIP Accounts window, searching for my work accounts, clicking on each one in turn and toggling them on and off, so I wrote a little GNOME Shell extension which gives you little switches in your panel to enable and disable (groups of) accounts.

Out of the box it just shows you one slider per account; and it comes with a really terrible application for configuring groups. You can get it from GitHub2. I’m pretty sure it doesn’t conform to the approval requirements for extensions.gnome.org so it’s not available there; and the configuration application could really use some love and caring. But it does work! If you like it, hooray; if you don’t, I’d love a patch. (Pre-emptively: if it doesn’t work on 3.4, that’s probably because I’m on 3.2, and I’d love a patch.)

(If you can’t read Haskell: (,) a b is another notation for (a, b). This defines types for two- and three-element tuples, with a default implementation of the Generic interface.) Okay so far? The file proceeds to define 4-tuples, 5-tuples, and so on until we get to the 8-tuple definition:

My new adventure at Collabora involves Wayland, like all the cool kids. I was distraught to learn that, since Wayland only provides clients with pointer position information to the surface currently under the pointer, and only relative to that surface, xeyes no longer works. We’ll see about that…

Watch a phone-cam video of the eyes in action1 in your choice of WebM or freedom-hating H.264! (I apologise for the shakes, but it yielded smoother results than the GNOME Shell screencast thing.)

The pointer’s position is provided to clients which request it, relative to a surface of their choosing. Thanks to the way surface transformations work in Weston, the eyes still work when rotated without any further effort:

Ready for the desktop!

Joking aside, I don’t really expect my branch to be merged any time soon, not least because it’s very much a proof-of-concept and is pretty easy to break. But it was a useful exercise in learning my way around the Wayland and Weston code-bases. The work involved was actually pretty small in the end:

Implement a pair of eyes which only work when the cursor is over them;

Define a protocol extension allowing clients to ask to track the pointer position relative to a surface;

Before we’d jokingly say “year of Linux on the desktop!” and laugh about how it would never happen, but my smiles had become bitter. A short way to put it is that writing high-quality software is not really a goal of the platform; stuff that doesn’t matter like continuously rewriting atop ever-changing platforms is. The scrappiness and free software spirit is what makes me love Linux as a hacker but I recognize now a deeper doom, that it will only ever broadly succeed by removing that spirit (e.g. Android).

I disagree that “writing high-quality software is not really a goal of the platform”, but there is an argument to be made that incrementally developing a high-quality platform (to enable writing high-quality software) makes life harder for third-party developers. It’s easy for free desktop developers—myself included—to underestimate the impact that tweaking the platform has on others, even if the changes make the platform more coherent in the long term. A common justification for churn is “the work is done by volunteers who wouldn’t necessarily spend their time on other things instead of this”, but that tends to ignore the other volunteers, caught up in dealing with unrelated changes, who would rather spend their time on other things.

This is not to say that platform-wide changes should be avoided at all cost: one of the great merits of the free software ecosystem is that it’s possible to make such changes. Nor am I claiming that volunteers cleaning up stagnant code bases is to be discouraged—quite the opposite. Nor is this an anti-GNOME 3 post, lest I be misinterpreted as thinking that Gtk+ 3, GObject Introspection and other leaps forward were a mistake. But taking advantage of this excellent new technology in applications does carry a cost in the short term.

Breaking with the “every six months or so maybe” release tradition, here’s the second Bustle release of the month. What’s the new hotness this time? You can record D-Bus traffic by just clicking File → New, and watch the diagram being drawn before your very eyes. After years of on-off development, Bustle can finally liberate you from needing to open a terminal to monitor D-Bus traffic1. Here’s a super-brief video tour.

Grab it for x86_64 or i486 today! Unlike the previous release, these work on both Debian and Fedora and have a strong change of working on pretty much anything with a modern-ish Glib and Gtk+22. (Thanks to my fellow Collaboran Guillaume for testing these tarballs, and to Scott Tsai for his suggestion.) Source and so on at the usual location.

Today’s surprising Bustle-assisted observation is that switching to and from the Shell overview causes the Shell to retrieve /desktop/gnome/shell/windows/button_layout from GConf 29 times. (Presumably that number is proportional to the number of windows I have open?) This was extremely useful for testing the live-logging feature, but is perhaps not ideal in many other ways.

A mere five months after I demoed its features at the Desktop Summit in Berlin, here’s Bustle 0.3.1. Whereas previous versions of Bustle only recorded and showed you the names, senders and destinations of D-Bus messages, this version also records and shows you the contents of the messages.

The statistics page also takes advantage of this new information: you can now get statistics about the sizes of messages in the log. Grab your copy today from the usual location. Beside the source, I’ve also uploaded a 64-bit binary tarball to save you some compilation time. Give me a shout if you have trouble with it. 32-bit version to follow when I get my chroots straightened out.

I have good news and bad news. Good news: here’s a 32-bit binary tarball. Bad news: seems like Debian and Fedora have differently-sonamed libpcaps. Why is distributing software so tedious?