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.”

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

Continuing on my “update side projects for Snow Leopard” theme, I’ve just rolled a new release of QLColorCode. I added support for a few new languages, including Scala, which is a personal fave. I also fixed a bug or two and finally upgraded the bundled version of Highlight from 2.6.6 to 2.12, which was long overdue.

On the ‘meta’ side, I moved the project’s source code from google code’s subversion to github. I’ve been using git a lot lately so I expect I’ll do the same for my other projects as well. Once you’ve gotten used to firing off branches for every little thing that crosses your mind and seamlessly switching between them at a moment’s notice it becomes hard to work in the SVN mindset again.

Unfortunately, QLCC has hit a bit of a roadblock with Snow Leopard. More specifically, it’s not SnoLep that’s giving me a headache, it’s Xcode 3.2. With the new Xcode Apple decided to include their own QL plugin for source code. That’s great, I say, more choice is good! QLCC will render everything that Xcode renders plus OCaml files, Scala files, and all sorts of other interesting languages that Xcode can’t handle. I’m not worried about QLCC losing in a fair fight. But no, Apple doesn’t fight fair.

It turns out that Quick Look always picks the Xcode plugin when rendering source code files (on my machine, at least). I don’t think the Xcode plugin gets special treatment, it just happens to win in the algorithm QL uses to resolve plugin conflicts. What is that algorithm? Nobody outside of Apple knows. It could be a coin-flip for all we know. Heck, after a reboot it’s possible QLCC will always win! In any case, when there are two plugins that both want to render files of type public.source-code it seems like maybe letting the user pick one would be a good idea, right? Apple doesn’t think so. No, they don’t want users to worry their pretty little heads about such matters. Don’t worry about the algorithm, don’t worry about making choices, it’ll all be juuust fine. Have a lollipop.

Except it’s not all fine. Because let’s say a user decides that they prefer QLCC over the Xcode plugin. Their only option for getting QLCC consistently and predictably is to somehow disable Xcode’s plugin. They could remove it, rename it, or move it somewhere that quicklookd won’t find it. But who wants to do something like that to an Apple-supplied file? Nobody. Even worse, Xcode’s application bundle is cryptographically signed. I believe that disabling the plugin by any of those means will invalidate the signature, though I haven’t confirmed this as fact.

Update: After further research, it appears that disabling the plugin will not invalidate the signature on Xcode itself, so there shouldn’t be any terrible consequences if you choose to do so. The plugin is located at: /Developer/Applications/Xcode.app/Contents/Library/QuickLook/SourceCode.qlgenerator

So anyhow, QLColorCode 2.0 is out. It works with Snow Leopard. If you have Xcode 3.2 installed you’ll probably never get to see it do its thing, but maybe one or two of you will still get something out of it.

For what it’s worth, quick look still sends .plist files to QLCC. Xcode’s plugin won’t touch those things.

Get it at the goog.

The change list is short and sweet. I’ve added UTIs for a few more languages (Tcl, JSP, Lua) and improved some highlighting modes. But the nicest change IMHO is the ability to configure the highlighting parameters with “defaults write …” commands. This means I can finally use my slateGreen theme day-to-day without worrying that I’m going to accidentally push it out as the default theme for the next release. It also means you can enable line numbers, wrapping, etc. without hacking on files in the QLCC bundle and worrying about your changes being overwritten on the next update.

BTW, QLCC has been downloaded over 5,000 times since I first released it. If only I had a dollar for each download…

Anyhow, get it at the project page.

Thumbnailing is supported now, and the syntax highlighting engine has changed from Pygments to Highlight, mainly because it’s about 10x faster but also because it covers more languages. It also has an ide-xcode theme that does a pretty decent job of imitating Xcode’s default colors!

Get it at the Goog.

Well, it turns out to be trivially easy to do a QL plugin that renders HTML. Mix in Pygments, the very capable syntax highlighting engine that can output HTML, and you’ve got a syntax highlighting QL plugin in under 100 lines of code!

Rather than host this project myself I’ve decided to try making a Google Code project. You can find it here:

http://code.google.com/p/qlcolorcode/

Enjoy!