Bustle 0.2.1

A couple of days ago, I released version 0.2.1 of Bustle, someone’s favourite D-Bus profiler. As the version number suggests, there aren’t really any big new features; most of the changes just make it a bit nicer to use, like showing you all the bus names a service owns, ellipsizing strings, a slightly less spartan UI, etc. Having finally gotten around to cutting a release, I’ve started wondering what to work on next. There are various small things I have in mind, such as searching, filtering, integrating the various statistic tools (bustle-time and friends) into the UI, and so on, but it’d be nice to have a larger goal to work towards.

One recurring feature request is the ability to see messages’ arguments. This isn’t currently possible because the simple plain-text logs produced by the monitor (which is a variation on the theme of dbus-monitor --profile) only includes the message header. I’ve thought for a while that the right thing to do would be to log the raw dbus messages, together with a timestamp, but wasn’t sure what the files would look like. (Maybe shove the timestamps into the message headers?) Rob had a nice idea: why not log to pcap files? This avoids inventing a new format—the UI would just use libpcap and feed each message through the dbus parser—and would also let you look at the logs in WireShark, if you’re into that kind of thing. I’m hoping to find some time to give this a shot soon. (Maybe on a cold Christmas evening, in front of a fire?)

In the meantime, have a peek at what your D-Bus-using applications are up to, and let me know what’s missing!

Telepathy BOF at the Boston Summit

Jason‘s hands were tired after typing two days of excellent notes on sessions at the Gnome Summit, so I took over writing up the Telepathy BOF (which was largely about Telepathy integration in Gnome Games).

Gnome Games’s tubes code is broken because of Empathy moving to Mission Control 5, which broke the contact chooser they were using (which used Mission Control 4). A Canonical person (your scribe did not catch who it was) has written a contact selector in C which just uses telepathy-glib, which Gnome Games will use and then start working again. This widget could form the basis of the long-anticipated telepathy-gtk.

Rob pointed out that it’s currently a bit of pain to request a channel for yourself: you can’t just call one D-Bus method and get a channel back, you also have to implement a Client.Handler object on which MC will call the HandleChannels() method. Sjoerd noted that Empathy has helper code for doing this in simple cases, which could be moved to tp-glib (it’s under the LGPL).

Jason wants a way to share high scores with your contacts. (Digression about a gnome-games high score server on gnome.org ensued, the notes of which your scribe lost in a kernel panic. One main point is that global high scores end up just featuring incredibly good scores and people setting their name to obscenities.) Jason wonders if g-g could publish your high scores to your contacts in the background?

  • Rob and Will suggested that in principle this could use PEP on XMPP, which allows you to publish a blob of information to your XMPP server and be notified when your contacts’ blobs change. (This is how Geolocation works in Empathy, for instance.) Unfortunately Google’s server doesn’t support PEP, so most people wouldn’t be able to use this; plus, it would need an extension in Gabble.
  • Another way to do it would be to initiate file transfers behind the scenes.
  • Rob suggested using tubes. Gnome Games would come with a tiny daemon that handles tubes for the “org.gnome.games.highscores” service, serving up your high scores to anyone who asks. Then, when you open a high scores table, it would use ContactCapabilities to discover which of your online contacts support that service, and then ask them for their latest high scores (with a cache and a rate limit, obviously). It could show a throbber while it’s doing this. Jason thinks this sounds like a good idea. Prerequisites: you need the latest MC and Gabble 0.9 in order for ContactCapabilities to work, but that’s it.

J5 wondered if any g-g people are documenting how they’re using tubes, because he was always confused by them, and he reckons this is a very important thing for app developers. Rob suggested pushing this into tp-book, and Sjoerd noted that Danielle has a helper which lets you say “give me a stream to this person” and get a GIOChannel back branch with methods to convert between telepathy address GValues and GSocketAddresses, which could conceivably be extended to set up a socket automatically. J5 thinks that if patterns for using tubes were really well documented, people would jump on the chance to use them.

Jason mentioned that people were discussing having a help option which jumps you to -games-$lang. J5 said that Ximian tried that, but found that people would just end up in empty chatrooms or paste goatse at each other. Integration with DevHelp would be nice to let people post examples etc.

J5 suggested that another good way to improve documentation is to make writing it a requirement for SoC. Rob noted that Telepathy hackers know that you need to use, eg., a Handler and a Tube, but it’s hard for people really immersed in the stack to remember which prerequisites people need to learn in order to understand that stuff. Sandy said they’d been discussing documenting requirements and standards for SoC students, and thinks it’s a great idea to ask students to blog stream-of-consciousness “this is what i did” updates. People have to make sure that they do this as they go along, because you forget the learning process after a few weeks.

Advantage of peer-to-peer high scores: you don’t get the problem of one incredibly good person dominating. suggested that you could make high scores decay over time, or once you reach a particular level, to address this problem.

Tetrinet is latency-sensitive: will that be a problem with Telepathy, particularly using MUC tubes? Rob said just try it and if it’s too slow it’ll get faster as the implementation of Tubes improves. Sjoerd noted that for tetrinet you probably want to just export the Tetrinet server over a multi-user stream tube, rather than using d-tubes.

Telepathy should use UPnP to make FT and tubes fast in more cases. This is on the TODO list.

Boston Gnome Summit and Maemo Summit

I’m just getting ready to fly away to Boston for the Gnome Summit. I’m looking forward to meeting people and seeing MIT, as well as getting the chance to spend more than a few hours in Boston (unlike every other time I’ve been there).

Inevitably, I haven’t been organised enough to propose a Telepathy- or Empathy-related session, but Rob McQueen, Sjoerd Simons, Andres Salomon, Dafydd Harries, Shaun McCance (when he’s not busy running a pair of interesting-sounding documentation sessions!) and myself will be around if people are interested; maybe something will coalesce. If window manager theming is more your kind of bag, Thomas Thurman‘s running a session on CSS in Metacity/Mutter. It’d be great to talk about integrating IM with the Gnome Shell; Moblin’s people panel and many parts of Maemo make interesting use of Telepathy, and it’d be nice to have something similar on the desktop.

Speaking of Maemo, going to Boston means I’m not at the Maemo Summit in Amsterdam, which is a real shame: I’d love to meet more of the Maemo community, hear what people have up their sleeves for the N900, and discuss how Telepathy could help. Happily, Marco Barisione‘s giving a talk about how Telepathy’s used on Maemo, and how you can use it too; relatedly, Travis Reitter and Mathias Hasselmann will speak about the address book, one of the heaviest users of Telepathy. Also, Marc Ordinas i Llopis is hosting a BoF on extending the (frankly stunning) Hildon desktop, and Ian Monroe is giving a talk with Sergiy Dubovik about preparing Qt4 applications for Fremantle and Harmattan. I hear Philippe Kalaf is also floating around somewhere. ☺

See you in (the wrong) Cambridge!

GCDS, D-Bus, Telepathy, and other items

Hello, internet! I’m at the Gran Canaria Desktop Summit. I’m a big fan of this “conference beside a beach” concept: interesting people, talks and projects, in the sun beside the Atlantic. There are a *lot* of Collabora people here; the head-count on the roof of the hotel last night exceeded 20, with still more people arriving today (and others stuck in Madrid). As ever, it’s good to catch up with colleagues and others!

Bringing GUADEC and aKademy together seems to have been a partial success. It’s interesting to learn about projects from the other side of the fence, and I’ve had some productive conversations about the state of using Telepathy in KDE. That said, it’s a bit sad that so much of the cross-desktop schedule seemed to be a talk about a GNOME implementation of a concept, followed by a KDE implementation of the same idea. Maybe putting the duplicated effort in people’s faces could help improve matters, but that seems unlikely.

Earlier today I gave a talk about profiling and optimizing D-Bus APIs (grab the slides!), including Bustle, a D-Bus visualization and profiling tool I’ve written to help visualize bus activity and find issues. I think it went quite well, and it lead to some interesting questions and discussions afterwards. In the talk, I mentioned a few examples of sub-ideal API design in other frameworks, but largely focused on the problems we’ve found in the Telepathy API, and how we’ve gone about fixing them. A couple of people mentioned that this might have reinforced the impression that Telepathy is really hard to use, which was not what I intended at all! On the contrary, the improvements I talked about have made Telepathy a lot more developer-friendly than it was when I first got involved: both the D-Bus API (if you ignore the deprecated bits) and the higher-level client-side convenience libraries (telepathy-glib and telepathy-qt4) have become significantly easier to use. It’s telling that a lot of the changes that have made developers’ lives easier have also made the D-Bus API more efficient, sane, and correct.

Of course, there’s still room for improvement. As I mentioned, contact lists are quite awkward to work with, which is a shame because most Telepathy UIs would like to use contact lists. 🙂 libempathy-gtk has a couple of contact list widgets you could reuse, some of which I’d like to see in a smaller, API-stable libtelepathy-gtk; I hear that there’s talk to extract the Python contact list widget that’s being written for GNOME Games to a library that other Pythonic Telepathy applications (such as pyhallebard for which I can’t find a website right now — thanks Anonymous!) could use.

In other news, Tracker 0.7 sounds (among other things) like a potential solution to the silly unfortunate situation where every music player uses its own library database, and thus your DAAP server either needs a separate database or to be built into your music player. Mojito looks pretty interesting; I’d love to see a UI for it on my desktop. It annoys me that I have to check so many disjoint sources at the moment. It might be nice if it could show me blog post titles from my LiveJournal or Facebook contacts; I suppose I should start hacking. 🙂

Bustle: a D-Bus activity charting tool

When working on Telepathy, I’ve often wanted to be see which D-Bus methods are being called on whom, when signals are emitted, and so on. Timing information is also handy: I’d like to figure out why cold-starting Empathy takes 12 seconds, and it’d be much easier if I could look at a diagram rather than staring at the unreadable output of dbus-monitor.

Previously, Alban wrote a tool that used a patched version of mscgen, and produced appropriate input with a dbus-monitor-like Python script. I wanted some more D-Bus-specific diagrams, and ended up reimplementing both the monitoring component (by forking dbus-monitor, as its --profile output did not contain quite enough information) and the diagram-drawing component (using Cairo). I’m happy to present an initial release of Bustle:

Screenshot of Bustle 0.1

There’s a Telepathy-specific hack in the tool to shorten object paths, but it shouldn’t make the tool any less useful for looking at other D-Bus traffic.

I haven’t made binary packages yet, I’m afraid, so you’ll need to grab the source tarball and build it if you want to try it out. In Debian-land, the dependencies are libdbus-1-dev libglib2.0-dev libghc6-mtl-dev libghc6-cairo-dev libghc6-gtk-dev libghc6-parsec-dev; see README in the source tree for how to build and use it.

The astute among you may have noticed from the dependencies that the diagram-building component is implemented in Haskell, using the excellent bindings to Gtk+ and Cairo. I got a prototype going within a few hours, and the strong correctness guarantees that the type system provides meant that I could refactor it mercilessly with confidence. I’m sure that I would have spent many frustrating hours chasing type bugs had I written it in Python, which is a more conventional high-level language for prototyping and writing tools like this. Next time you’re frustrated by such bugs, you should give Haskell a try. 🙂

Edit: Bustle now lives at willthompson.co.uk/bustle.

The near-impossibility of teaching programming to a subset of students

The camel has two humps[pdf] was an interesting read; a bit wooly, but believable. One of my favourite paragraphs, tangential to the paper’s findings, concerned IDEs:

Programmers, who on the whole like to point and click,
often expect that if you make programming point-and-click, then novices will find it easier. The
entire field can be summarised as saying “no, they don’t”.