n8blog
distraction in action

Like my work? Check out HexaLex, my game for iPhone & iPod Touch. It's a crossword game like Scrabble, but played with hexagonal tiles. http://www.hexalex.com

As QLColorCode fans are aware, Snow Leopard’s version of Xcode has caused some trouble for me. To wit, Xcode 3.2 shipped a Quick Look plugin that registered for the public.source-code uniform type identifier1 (UTI), which is the primary UTI that QLCC registers for so it can do it’s magic. In the world of applications it’s possible to bring up the Finder’s Get Info dialog on a file of a given type and assign it and it’s kin to some application, but there’s no such interface for Quick Look plugins. Thus, there is no way to express a preference for QLCC over Xcode without removing or renaming the Xcode plugin.

To make matters worse, the system’s top-secret non-configurable algorithm for resolving conflicts appears to work backwards from what users might hope for. The Xcode plugin lives inside an Apple-supplied app bundle in a system directory. It’s installed automatically if you choose to install Xcode itself, so it can easily up on your system without you even knowing it. Compare this to QLCC. You, the user, have actively downloaded it and installed it for the express purpose of handling source code files in the Quick Look system. You can easily remove it if you decide you don’t like it anymore. Which plugin do you think should win if they conflict? Apple thinks different. The system always picks the Xcode plugin over QLCC.

But come on, if you’re going to have a system like this there ought to be a way of saying “I want plugin X to handle UTI Y.” This could be a nice shiny user interface somewhere or a down-n-dirty terminal command, but it needs to exist. I sent a bug report to Apple saying as much (rdar://7240036, mirrored here). I described my problem and made it clear that the solution ought to be a preference system for Quick Look. At the very least, I said, user-installed plugins should rule supreme.

Apple engineering’s response? You can register for more specific UTIs than public.source-code. Nothing about why they don’t want to have a preference system or let user-installed plugins override others. Just “register for more specific UTIs.” The idiocy of this suggestion is staggering. The whole purpose of the hierarchical nature of the UTI system is to allow folks like me to say “I handle source code” without having to list every type of source code. Highlight, the library that QLCC is based on, can colorize about 140 programming languages. Apple engineering, with a straight face, is telling me that I should be registering for 140 UTIs because Xcode decided to register for the one I actually need.

It gets worse. Even if I decided to take Apple’s advice, it’s impossible to say what those 140 UTIs should actually be, because there’s no central authority for registering UTIs. (This is another glaring flaw with the UTI system as implemented by Apple.) UTIs like org.ocaml.ocaml-source are generally defined and bound to file extensions like .ml by applications or other entities like Quick Look plugins. So what happens if you install one app that binds .ml to org.ocaml.ocaml-source and another that binds it to fr.inria.ocaml-source? Your guess is as good as mine. That’s another bit of non-configurable secret sauce. But I think it’s safe to say that only one will win.

So let’s go back to my hypothetical 140-UTI plugin. Imagine the confusion and headaches when a user’s .ml files stop being highlighted just because she happened to download some random app that bound .ml to fr.inria.ocaml-source and my plugin has registered for org.ocaml.ocaml-source. Can you imagine trying to solve these problems for random users of 140 programming languages, of which you actively use maybe 10?

But really, this is just an example of brush-off via bug report. Despite my slagging I do believe the engineers at Apple are generally quite talented and bright. They must know that the problem exists, but for whatever reason they’ve decided it’s not worth solving. Furthermore, they’ve decided it’s not worth telling some no-name hacker why they think it’s not worth solving. But the most insulting thing is that they didn’t even bother to mark my issue as a duplicate of some other issue requesting a prefs system for Quick Look. (You’d better believe that one exists.)

“Go register for more specific UTIs, kid, yer bothering me.”

1 If you’re unfamiliar with the UTI system, John Siracusa’s encyclopedic review of Tiger has a detailed description.

  • Share/Bookmark

  Comments:

1. Berend Hasselman replies:

It’s not only annoying that Xcode (and by implication Apple) decided to hijack the source code QLooking. They didn’t even mention anything during installation.
I agree that Apple’s suggestion is idiotic even arrogant.

I want to decide which QL plugin to use; I’ve been using yours for as long as it has been available and it bets the pants off the alternative.

It would be very easy for Apple to provide some sort of option to not use Xcode’s source code quicklook plugin.

2. Seth replies:

If any readers have developer accounts, they too can file a bug on this issue as I’ve done here:

http://openradar.appspot.com/7257190

I have heard that one way Apple prioritizes bugs is by number of duplicates, so if this issue is important to you it may well be worth the time it takes to report it.

3. n8 replies:

Thanks Seth!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre lang="" line="" escaped="">

Please type this word with the letters reversed: live

Like my work? Check out HexaLex, my game for iPhone & iPod Touch. It's a crossword game like Scrabble, but played with hexagonal tiles. http://www.hexalex.com