Will Thompson

Once upon a time, three intrepid individuals 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). ((Top designers agree! To quote Allan Day, “I could live without contacts on a map ;)”.)) 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.

I have a lot of IM accounts ((32, since you ask)). 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 GitHub ((“rah rah why GitHub?” Call it an experiment.)). 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.)

I spent most of last week holed up in a meeting room at Collabora Towers with Michael Meeks (of SUSE) and Eike Rathke (of Red Hat), working on a prototype of collaborative spreadsheet editing in LibreOffice Calc, using Telepathy tubes to start editing sessions with your IM contacts. Michael’s got a much more extensive and eloquoent post about where we got to, and here’s a quick screencast of the prototype in action!

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 action ((with unintentional soundtrack by Marco, Jo and Daniel)) 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;
• Plumb it into the compositor and client.

Now onto something a little more useful…

Alas, Evan Martin’s excellent series of blog posts from the Chrome-on-Linux salt mines has come to an end. His sabbatical apparently didn’t relieve his general malaise, which he explains thusly:

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.