iTunes, Cocoa, and Dock Drags
• Chris Liscio
In my iTunes dragging post from a while back, I described a method for handling iTunes song drags on the Dock.
Since iTunes 10.4 was released recently with Cocoa under the hood, I thought I should take a look at the dragging situation again. I wrote a little test application that dumped the NSPasteBoard types coming in from a drag, and obtained the following list:
As far as I can tell, the
com.apple.itunes.metadata type on the pasteboard is new in iTunes 10.4. Digging deeper, I managed to dump out the NSString contents of this item on the pasteboard:
This looks a whole lot like the information that was present in the old CorePasteboardFlavorType item. You can iterate through the list of tracks in the dictionary, and there's your file's location URL!
While it's great that we can now (slightly more) easily obtain the track's location, it's quite odd that the
com.apple.pasteboard.promised-file-url item on the pasteboard isn't enough to get the dock icon to recognize the drag as a supported file. Capo happily accepts .m4a files, but this drag is apparently not good enough for the Dock to accept it. Developers shouldn't have to implement a service to accept song drags from iTunes.
Using the dictionary on the pasteboard could also be fragile over time. If someone on the iTunes team decides to manipulate the "schema" inside the dictionary in a future version of iTunes, there will be some painful transition required. Luckily for us, there appears to be some kind of versioning present in the dictionary, so we could cope with multiple versions of iTunes drag formats in the future. (Provided the schema-changer in question is smart enough to update the versioning…)
It still works, for now. There's no need to go out and rush to fix this issue today: the old-style item on the pasteboard is still present. Going forward, you just have to add the new pasteboard item UTI, in addition to the one we declared to wrap
CorePasteboardType 0x6974756E in your service's NSSendTypes.