anthonygelibert/QLColorCode

HTML/XHTML types are not working with QLColorCode after updating LSItemContentTypes

Closed this issue · 8 comments

bxsx commented

Hi,

I added the following lines into ~/Library/QuickLook/QLColorCode.qlgenerator/Contents/Info.plist:

<dict>
        ...
        <key>CFBundleDocumentTypes</key>
        <array>
                <dict>
                        <key>CFBundleTypeName</key>
                        <string></string>
                        <key>CFBundleTypeRole</key>
                        <string>QLGenerator</string>
                        <key>LSItemContentTypes</key>
                        <array>
                                <string>public.xhtml</string>  <!-- this -->
                                <string>public.html</string>   <!-- this -->
                                <string>public.source-code</string>
                                ...

Log out/log in, qlmanage -r or moving ~/Library/QuickLook/QLColorcode.qlgenerator out of the directory and back. Nothing helped. The QL still launches the system Web.qlgenerator.

I also tried to disable the html/xhtml by commenting out the items from /System//Library/QuickLook/QLColorcode.qlgenerator, this however requires disabling SIP to save the changes (it didn't save the file even with sudo).

Is it possible to see HTML source code instead of a preview of the webpage in macOS Catalina?

PS. Of course the files I try have following output:

$ mdls -name kMDItemContentType test.html
kMDItemContentType = "public.html"

No, Catalina cannot allow to customize the quicklook for html files.

bxsx commented

No, Catalina cannot allow to customize the quicklook for html files.

I wasted 2 hours to make it work. Ehh. I assume this is a general rule of any system-wide installed qlgenerators from /System/Library/QuickLook ?

bxsx commented

My assumption is definitely wrong. Text.qlgenerator handles JSON and other files by default that are easily overridden.
@sbarex could please explain why it's not possible to customize it explicitly for the HTML files?

Is not documented, but so far no one has been able to customize the preview for a number of formats: plist, xml, html, ts, jpg, gif, png...
Neither with the deprecated qlgenerator system nor with the new appex extension.

bxsx commented

OK, I found few opened issues regarding this story on other gl generators, so I am up to date now ;)

I notice you are quite active about this issue. However, maybe you missed this one: whomwah/qlstephen#87

Anyway, I tried to create several dynamic UTIs for HTML:

?0=7:3=text/html:1=html
?3=text/html
?1=html

I added encoded results to the supported list. Unfortunately, it didn't work.

However, I was successful to launch the preview manually:
$ qlmanage -g ~/Library/QuickLook/QLColorCode.qlgenerator -c - -p file.html

Oh, very interesting indeed! I hadn't seen that comment. I finally understood how dynamic UTIs are generated. I had always wondered if they were unique to the machine in which they are generated or universal. Now I know they are universal.

I did a quick test to add the support for the xml format but was unsuccessful with my application. Some more investigation will be needed.

bxsx commented

IMHO its not possible at the moment.
It's working correctly while launching via qlmanage but even if you remove in recovery mode the Web.qlgenerator system still use it (haven't tried it myself though). My guessing is that Apple has changed a code and don't even take a look into available extensions, I wouldn't be surprised if for "built-in" types this is hardcoded. I'm just wondering how they managed to get back Web.qlgenerator even if it was removed. Maybe macOS checks for missing files and redownloads/recopied from Internet/Recovery Disk? @sbarex after removing built-in qlgenerators, do they reappear physically on your hard drive in /Library/QuickLook/ ? Or they seems to be working without physical existence (I barely believe in this)?

I only tried once to remove the system qlgenerator and I also saw that it continued to be used despite being removed. However, I prefer to avoid tampering with system files, so I didn't go through that kind of test.