Panflute is the new black Music Applet.

Let me explain.

Panflute is slated to be the successor to Music Applet. Its fundamental architectural change is the complete separation of the part that draws the panel applet from the part that figures out how to talk to the backend music player. By “complete”, I mean that Panflute makes them entirely separate programs. This opens the possibility of other software also using the Panflute backend instead of figuring out its own way to talk to a dozen different music players. A panel applet is just one possibility — you might want a desklet, or whatever GNOME 3.0 will replace panel applets with, or an alarm clock, or something else I can’t even think of.

The goal of the Panflute backend is to make everything look like it has a nice, clean MPRIS interface. MPRIS is great because it specifies a common interface for programs to talk to music players. MPRIS isn’t so great because many popular players (such as Rhythmbox and Banshee) don’t use it, and many players that do implement it either deviate from the spec in some areas (such as Audacious) or have some odd quirks about their interpretation of the spec (such as Amarok). The Panflute backend papers over all these issues, presenting a single, common, consistent interface, regardless of what player is actually running. It also adds some (clearly marked) extensions to MPRIS to provide features not available in MPRIS 1.0, such as setting metadata (particularly ratings) for the current song, or having a convenient way to get updated position information without having to resort to polling.

Panflute also provides a panel applet to replace the old Music Applet. At this time not much has changed feature-wise, but by doing a ground-up reimplementation, I’ve been able to throw out a bunch of legacy code to work with now-fairly-old libraries and to redesign things to support more flexible layout of the applet’s content, such as the oft-requested support for fat panels.

Perhaps most importantly, however, is the fact that I’m using Launchpad to host development of Panflute instead of doing things directly off of This means I’ve now done something I should’ve done a long time ago and started using a proper bug tracker instead of relying on e-mail. Finally.

The plan for now is to get Panflute up to feature-parity with the most recent release of Music Applet and make that a 0.something release. The 1.0 release will try to include as many feature requests from Music Applet as I can manage, as well as a testing tool to help verify that the code that handles talking to each music player works as expected, and to map out what functionality isn’t available. (Hey, that’s another thing that can exploit the applet/backend separation!) The 1.0 release should also make sure those player support modules implement as much of the MPRIS spec as possible; so far I’ve been focusing on the /Player object (which the applet makes heavy use of) and largely ignoring the /TrackList object (which it ignores completely). Obviously, for the Panflute backend to be generally useful for other developers, it needs to be full-featured.

I really ought to formalize the above paragraph a bit and get a proper blueprint for future development up in Launchpad….

Anyway, the Panflute code hosted on Launchpad is functional, with all applet features except pop-up notifications implemented and backend support for Rhythmbox, Banshee, Amarok, Audacious, Muine, and VLC implemented. There’s still some rough edges, particularly how the applet doesn’t yet bother to start the backend process, but those issues will be easy enough to fix. (And now that there’s an actual bug tracker, you can file a bug if something is amiss and/or missing.)

8 Responses

  1. Kulini…flute?

  2. “Music Applet” didn’t have “box” anywhere in it, so why would Panflute stop you?

  3. As soon as I saw the first few lines, I scrolled down to the comment section, hoping to beat Jamie and Benji to posting “Kuliniflute”, no joke.

  4. Pretty good job , but I think it needs a scrollbar to move the song time or to jump to another part of the song. thanks

  5. First, Kuliniebox came from my understanding that Music Applet worked with Rhythmbox and that you had expressed palpable annoyance with the applet being called Kulinibox.

    Clearly, the thing to do here is to combine your name, Music Applet, and PanFlute together. Kuliniepanapple? Flutappletiewicz? Windows Media Player?

  6. Alonso: Some way to do that is in the works, but right now I’m focusing on reaching feature-parity with Music Applet before I start adding new things. To make sure your request doesn’t get lost, I suggest filing a wishlist bug.

  7. I wouldn’t hold your hopes up for Rhythmbox and Banshee implementing MPRIS any time soon, if ever.

    At the time it was being developed/presented, I (being Rhythmbox maintainer at the time) had quiet a few arguments about the spec with it’s author. I think most of them were around things that are very different between playlist-based (XMMS, VLC) and library-based (Rhythmbox, Banshee) players. I think there were several method that if we implemented, it wouldn’t be safe to use them from clients because the behaviour wouldn’t be at all the same.

    If I recall correctly, abock and I had a discussion about creating a competing “common music player” spec, which we never got around to :)

  8. I’m not surprised about the /TrackList calls not being meaningful for Rhythmbox; I didn’t see any reasonable way to implement them either. Thus far in development I’ve been leaving them unimplemented for everything except the players that already use MPRIS. I don’t know if it will turn out to be worthwhile to make another set of methods for library-based players, since I’ve already added a few extension methods for features that aren’t available through MPRIS, such as setting song ratings.

Comments are closed.