Clash with BetterZipQL.qlgenerator

[chrisridd]

The BetterZipQL.qlgenerator clashes (i.e. gets used instead of) with the epub.qlgenerator on Snow Leopard, but not Lion. I've got Snow Leopard in a VM and can reproduce this.

It looks like they're claiming to support files with the .epub extension in their Info.plist:

<dict>
    <key>UTTypeConformsTo</key>
    <array>
        <string>public.zip-archive</string>
        <string>com.pkware.zip-archive</string>
    </array>
    <key>UTTypeDescription</key>
    <string>Zip Archive</string>
    <key>UTTypeIconFile</key>
    <string>Zip</string>
    <key>UTTypeIdentifier</key>
    <string>com.macitbetter.zip-archive</string>
    <key>UTTypeTagSpecification</key>
    <dict>
        <key>public.filename-extension</key>
        <array>
            <string>pk3</string>
            <string>pk4</string>
            <string>nth</string>
            <string>xpi</string>
            <string>swc</string>
            <string>epub</string>
        </array>
    </dict>
</dict>

I don't understand the Mac's UT system, but this seems to override the epub.qlgenerator's use of the epub extension and org.idpf.epub-container.

Hacking the <string>epub</string> line out of their Info.plist seems to work, but is an unreasonable thing to do IMO.

[jaketmp]

BetterZipQL is abusing the UTI system (see here under 'Recommendations for Declaring new Uniform Type Identifiers'), using com.macitbetter.zip-archive as a convenience to support a whole swathe of zip-derived filetypes without defining individual UTIs. Mac OS X 10.7 declares org.idpf.epub-container as the UTI for epub files, and I've imported it into the epub.quicklook plist.

Under Lion, the system defined UTI trumps the BetterZipQL UTI, and as epub.quicklook imports the system type, we work fine. I don't think the behaviour of clashing UTIs is defined, but really BetterZip should import the Lion UTI.

However, after writing all that, it still doesn't answer the question of how the system picks which quicklook generator is selected when two offer to preview the same UTI. I suspect it follows the usual /System/Library trumps /Library trumps ~/Library pattern, with generators at the same level being picked alphabetically. It would be interesting to see what would happen if you where to rename epub.quicklook to _aaepub.quicklook.

Either way, I think the way epub.quicklook works is correct, but I'm not sure if there's something we could do to mitigate this kind of clash.

[chrisridd]

Ha ha, renaming to aaepub.qlgenerator worked!

I wonder if pinging the BetterZip folks would be worthwhile.

[jaketmp]

Could be - are you a paying customer? Otherwise I'll drop them a line.

Searching about, the folks behind qlcolourcode seem to have the same problem - and their solution is to disable the conflicting plugin, which doesn't seem to bode well for a simple fix.

At least the renaming trick will work on a case-by-case basis.

[chrisridd]

I'm not a customer. Someone on the mobileread.com forums noted the problem, but they're not too communicative.

[jaketmp]

While not really resolved, there is no fault here - and I think the note in the readme is prob the best we can do until Apple implements a better way to handle conflicting plugins.