How to make your app’s Dock tile highlight
So, no matter what you do, your Dock tile doesn’t highlight when you drag a document onto it. You’ve hexadecuple-checked your CFBundleDocumentTypes list, and everything looks correct, but Dock is not co-operating and you just want to kick it.
Finally, you decide to remove the LSItemContentTypes key, and it works just fine! How can this be?
Well, since Tiger, LSItemContentTypes shuts out all the other document-type tag keys. Your CFBundleTypeOSTypes, your CFBundleTypeExtensions—all of those are ignored when LSItemContentTypes is present; it looks at nothing but the LSItemContentTypes list. Taking out LSItemContentTypes forces LS to look at your OSTypes and extensions lists instead.
More to the point, your problem is that the set of UTIs you’ve specified does not contain the UTI of the would-be document that you’re dragging.
You could be forgiven for expecting that having com.apple.application in your set of UTIs would allow you to open applications as your documents. This is not true, because a standardly-constructed Mac OS X application is of type com.apple.application-bundle. That type does conform to com.apple.application, but it is not equal to com.apple.application, so the Dock refuses your drag with a dismissive wave of its kerchief bundle and an AIFF file of a sharp “hmph!”.
So how do you find out the true UTI of your document?
The easy way is mdls. Ask for the kMDItemContentType property:
% mdls -name kMDItemContentType Foo.app
Foo.app -------------
kMDItemContentType = "com.apple.application-bundle"
But this only works on a volume with a Spotlight index; for example, it doesn’t work on disk images or RAM disks (same thing). Another way is Nicholas Riley’s launch, with its -f option:
% launch -f Foo.app
Foo.app: Mac OS X application package
type: 'APPL' creator: …
architecture: PowerPC, Intel 80x86
bundle ID: …
version: …
kind: Application
content type ID: com.apple.application-bundle
contents: 1 item
created: 2007-07-23 07:12:31
modified: 2007-07-23 07:12:31
accessed: 2007-07-23 07:12:41 [only updated by Mac OS X]
backed up: 1903-12-31 17:00:00
Either way, put that UTI into your list. Then drags will work.
In summary, the Dock checks for equality of the prospective document’s UTI to the UTIs listed under LSItemContentTypes, not conformity. You need to list every UTI you support in your Info.plist, including those that conform to the ones you expect. It’s either that or give up on UTIs entirely.
(Summary suggested by wootest.)
UPDATE 08:44: ssp suggested mdls instead of launch.
July 23rd, 2007 at 07:15:21
If it’s not an application you are developing but just one you want to use, Command-Option dragging may help as well.
Perhaps just using the mdls command is an even easier way to learn a file’s UTI, btw.
‘mdls -name kMDItemContentType PATHTOFILE’
July 23rd, 2007 at 07:43:18
launch actually works in circumstances where mdls doesn’t. For example, I performed the above example on a RAM disk. Here’s what mdls says:
For those who haven’t seen it before, here’s the normal output, as determined by cding into my /Applications folder and mdlsing one of the applications there:
So mdls doesn’t work on volumes without a Spotlight index. launch works anywhere.
July 23rd, 2007 at 08:56:42
I feel I should add that 10.5 (“Leopard”) will improve on this by adopting UTIs everywhere, but it doesn’t mean you can add them to your existing apps because 10.4 will still fuck this up.
And Peter started looking into this because I was having trouble supporting a feature in an upcoming ThisService release, where you should be able to drag any script file to its dock icon to trigger opening it (but implementing the opening behavior as simply placing it in the script file picker). Right now, I think I’ll either stick to one entry containing all extensions for common scripts (+ AppleScript’s OS types) or to one catch-all entry (which would be bad since it’ll show up in Open With in the Finder.
Command+Option is a clear workaround but I should be able to do this using just two UTIs, in my opinion: `com.apple.mach-o-binary` (for compiled UNIX pass-through filters) and `public.script` (underlying both AppleScripts and command-line style scripts like shell scripts and PHP/Perl/Ruby/Python/etc.).
July 23rd, 2007 at 09:18:27
Actually, I had resigned the problem yesterday, but came back to it while working on an application of my own that I’m going to release later today.
July 24th, 2007 at 07:34:02
Hi. Just wanted to let you know that there seem to be typos in http://feeds.feedburner.com/domainofthebored where it’s referring to http://boredzo.org/blog/archives/2007-07-24/configure-application-dock-tile, which doesn’t exist, rather than to http://boredzo.org/blog/archives/2007-07-23/configure-application-dock-tile.