More of a programming nerd than is strictly healthy. See also {nevyn.nu, thirdcog.eu, twitter}

Projects

Overooped

File format plugin API for Spotify?

At Spotify, we have one and a half day of ‘hackday’ (‘code whatever you want’, the ‘20% time’ concept from Google) every sprint. Since the past few months have been a bit hectic finishing up the new 0.5.0 release, we haven’t really had time for that in a while, and thus compensated by having a whole week of crazy hacking this week. I managed to finish two features in that time; one in the iOS client (of which I will only say: Loren Brichter is my hero!), and one in the desktop client: file format plugins.

Last year, one of my hackday projects was integrating blargg’s Game Music Emu into Spotify, thus letting you play NES, GameBoy, SNES, Genesis, PC Engine and other console’s music files in Spotify. Just a few days of work, and suddenly I had the best console music player app in the world, with playqueue, playlists and whatnot. However, GME is LGPL and we statically link our dependencies, so there was no way I could release it :(

Thus, I aimed to hit two birds with one stone: by adding a file format plugin API to Spotify, I could a) enable anyone to add support for their favorite file format in Spotify (flac, mikmod, sid, …) b) let me release the GME support as an open source plugin!

However, I’ve never designed a plugin API in C before, and if we’re going to release it and support it for quite a while, it should be well designed, easy to use, and cover all the basic needs. It’s versioned, so it should be simple to add new things to the API, but changing the existing ones might be tricky. So, my question is: do you have any feedback for me on this api?

Media keys hook in Mac OS X

There is no nice (or is it even official?) way of detecting and handling the media keys on the user’s keyboard. One can intercept events with type NSSystemDefined and subtype 8 in -[NSApplication sendEvents:], but this has major problem: any other applications that listen to the media keys will receive these events too. This means for example that if only Spotify is running and you want to pause your music, iTunes will start when you press play/pause. If you have VLC running in the background, it will also start playing.

Apple has solved this problem internally by having their media key using applications cooperate and resign media key controls to the application that was in the foreground most recently. However, there is no way for third party applications to join this cooperation.

I have implemented a workaround that does this using a CGEventTap in the Cocoa class SPMediaKeyTap. The advantage of using an event tap instead of just intercepting the events in -[NSApplication sendEvent:] is that you have the power to throw the event away. This way, we can decide to “own” the media keys and be the only app that listens to them.

This class is smart enough to resign the media key event tap whenever another application that we know will want to use the media keys becomes active, and keeps track of which media key using app was recently started.

If everyone uses this class, and everyone add each other’s bundle ID to that list of whitelisted bundle ID’s, we’ll get nice behavior from all apps. An even better solution would be if Apple provided a way of acquiring the media keys.