Doesn't work on 10.15

[CarlosAMendoza]

Needs to be signed so macOS can use it.

[rileytwo]

Is this what you're seeing @CarlosAMendoza?

However, if I run qlmanage -p .hyper.js, I get a full preview:

[adityasrini]

No it does not work. GA Catalina. This is the error message I get:

Testing Quick Look preview with files:
	index.js
2019-10-07 20:03:28.975 qlmanage[30011:113479] *** CFMessagePort: bootstrap_register(): failed 1100 (0x44c) 'Permission denied', port = 0x6633, name = 'com.apple.tsm.portname'
See /usr/include/servers/bootstrap_defs.h for the error codes.
2019-10-07 20:03:33.461 qlmanage[30011:113479] *** CFMessagePort: bootstrap_register(): failed 1100 (0x44c) 'Permission denied', port = 0x6e07, name = 'com.apple.coredrag'
See /usr/include/servers/bootstrap_defs.h for the error codes.

EDIT: Command was qlmanage -p index.js. I also tried sudo qlmanage -p index.js. The only difference was that with sudo I didn't get the warnings that this plugin was untrusted and should be moved to the Trash can.

[adityasrini]

I tried the steps from this issue in a related plugin and this time, I get a "this preview cannot be safely displayed in quick look" warning.

[kallewesterling]

Same here. When I try to preview a file, here's what I see:

[rileytwo]

While notarizing the app would get rid of that notification, I don't think it would solve the overall issue. You can disable that by running sudo spctl --master-disable (I'm not recommending doing so, I'm just stating this in case you want to try previewing the file without that notification popping up).

I'm able to preview the icon, but still no file preview when pressing space. I'm still getting the same file preview as above

[rileytwo]

After looking around in the logs, I'm able to get this (this is for the .hyper.js file above):

Preview failed due to security risk: web page's main frame was asked to load a url that is not a file URL, and does not conform to html or xml.

[sbarex]

After looking around in the logs, I'm able to get this (this is for the .hyper.js file above):

Preview failed due to security risk: web page's main frame was asked to load a url that is not a file URL, and does not conform to html or xml.

On GeneratePreviewForUrl.m, at line 61 you must add the mime type definition to the properies variable. So the patched code is:

CFDictionaryRef properties = (CFDictionaryRef)@{
        (__bridge NSString *)kQLPreviewPropertyTextEncodingNameKey : textEncoding,
        (__bridge NSString *)kQLPreviewPropertyMIMETypeKey : @"text/html",
    };

[sbarex]

after numerous attempts I have notarized the plugin. After the change I suggested above for adding the mime attribute now works on catalina!

the steps are:

• QLColorCode target, on Build Settings, show all settings and the on signing section set:
  • Code signing identity: Developer ID Application
  • Code signing inject base entitlements: No
  • Code signing style: Manual
  • Developer team: set your team
  • Enable hardened runtime: Yes
  • Other code signing flags: --timestamp

Build the plugin then create a zip:
$ /usr/bin/ditto -c -k --keepParent "*folder containing qlcolorcode.qlgenerator*" QLColorCode.zip
Then send the zip for notarization whit your appleid user id ad a application password for login:
xcrun altool --notarize-app --primary-bundle-id "org.n8gray.qlcolorcode" -u "*appleid user name*" -p "*app password appleid*" --file QLColorCode.zip
After the notarization is complete staple the result:
$ xcrun stapler staple QLColorCode.qlgenerator

I use an Apple Developer Subscription account. I did not understand if it is possible to notarize with a free account.

I have found more info for notarization on https://stackoverflow.com/a/56799591/1409904

Anyway Apple has deprecated all quicklook api like QLPreviewRequestSetDataRepresentation and suggests to use QLPreviewingController in a Preview Extension (see http://codeworkshop.net/objc-diff/sdkdiffs/macos/10.15/QuickLook.html). But I don't have found any info for use QLPreviewingController on macos.

[rileytwo]

@sbarex the links are taking me to an issue search on this repo

I'm enrolled in the dev program also, but I don't think it's possible to notarize without a paid developer account. There isn't really an official (or clear) statement from apple about it, but everything I've found on the internet points to needing a paid developer account to notarize. Are you not getting any errors in Console.app after adding in those lines?

[sbarex]

@sbarex the links are taking me to an issue search on this repo

I'm enrolled in the dev program also, but I don't think it's possible to notarize without a paid developer account. There isn't really an official (or clear) statement from apple about it, but everything I've found on the internet points to needing a paid developer account to notarize. Are you not getting any errors in Console.app after adding in those lines?

On Console.app, searching for com.apple.quicklook as suggested from qlmanage with -d arguments (that it is also deprecated...) don't show any errors when open a preview of a source file.

But there are some errors when generating thumbnail on Finder with icon view (in detail view the associated application icons are shows for the file and not the preview):

• No sandbox token for thumbnail request , it will probably fail
• Failed to unarchive thumbnail's generated properties: Error Domain=NSCocoaErrorDomain Code=4865 UserInfo={NSDebugDescription=}

The resulting icon are all black (i use the zenburn theme).
With qlmanage -t the icon is generated correctly.

[rileytwo]

I was able to get it working with your instructions @sbarex!

[jonluca]

Thanks for the help @sbarex - @anthonygelibert is there any chance that a notarized version of the binary will be published/released?

Additionally, shouldn't disabling notarization sudo spctl --master-disable make it work? It's still not working after disabling SIP and notarization.

[CarlosAMendoza]

A signed binary would be great for those who don’t have their own developer account. Also thank you for fixing the issue.

[alexclst]

Honestly, even though I have a developer account I would rather that the person responsible for past releases make a notarized binary available than building and notarizing this plugin myself, because then the notarization for the plugin is entirely within its actual developer’s account with Apple. I just don’t think that many people should notarize what is the same version of the same plugin, but maybe that is me just figuring it may come back to bite us at some point.

Plus, the issue is with virtually all but one of the QuickLook plugins I had pre-Catalina. We can option-click apps to bypass the security settings stopping us from using them (or at least we could pre-Catalina, haven’t actually run into a need to do that yet on Catalina), but cannot for QuickLook plugins. So another fix would just be an update to Catalina allowing us to option-click plugins to bypass security checks. Unfortunately that doesn’t seem likely to ever happen.

[rileytwo]

@alexclst I get what you're saying. I don't think @sbarex was suggesting everyone notarize it themselves (nor was I), but instead was showing how the issue can be resolved. I'm glad that they listed out the steps to "fix" the problem because there's not many other resources to help with a Quick Look problem like this one.

Since Quick Look plugins are deprecated and will not working in future releases of macOS, it may not be worth @anthonygelibert's time and money to sign up for a developer account just to notarize QLColorCode, if he doesn't already have a developer account.

[sbarex]

Unfortunately I don't have a personal developer account to use to share the compiled version of the plugin and I can't use my company account for this.
I really hope Apple doesn't want to delete quicklook because it was a very useful and unique macos feature.
From the little that I understood, however, I think that more developers can notarize the same executable. When executing the program, I suppose macos only checks the presence in Apple's database of a softare that corresponds to a certain hash signed by a certain author and not searching for a specific executable...

[alexclst]

Apple isn’t deleting Quick Look, but just requiring that what used to be separate plugins be App Extensions instead. At least, that is my take on seeing Quick Look as a part of the Extensions preferences in System Preferences:

[adityasrini]

If the maintainer doesn't have the bandwidth to notarize this, perhaps someone from the community can request to become the maintainer or fork and notarize this themselves?

[adityasrini]

I have very limited Objective C knowledge to be able to discern and code review PRs and issue fixes to bugs so I'm not so sure about doing this myself.

[sbarex]

Apple isn’t deleting Quick Look, but just requiring that what used to be separate plugins be App Extensions instead. At least, that is my take on seeing Quick Look as a part of the Extensions preferences in System Preferences:

oh good! do you have found any source example?

[rileytwo]

@sbarex does qlcolorcode still work for you between reboots? Even if I'm able to get it working through building, signing, and notarizing the bundle, it doesn't work the next time I boot my mac up

[alexclst]

oh good! do you have found any source example?

Apple’s sample code for Building an App Based on the Document Browser View Controller talks about previewing custom document formats. This is talking about iOS, but both iOS and macOS now seem to share the same Quick Look Preview Extension target type for building these new App Extension based Quick Look plugins that this sample code includes. I know nothing about the old .qlgenerator plugins at the source level, so would have no way of telling you how different or not this new API is from that which is now deprecated.

[sbarex]

@sbarex does qlcolorcode still work for you between reboots? Even if I'm able to get it working through building, signing, and notarizing the bundle, it doesn't work the next time I boot my mac up

I'm using catalina on vmware fusion for testing before upgrading my mac. For now after the full reboot of the virtual machine the plugin works correctly.

[sbarex]

Apple’s sample code for Building an App Based on the Document Browser View Controller talks about previewing custom document formats. This is talking about iOS, but both iOS and macOS now seem to share the same Quick Look Preview Extension target type for building these new App Extension based Quick Look plugins that this sample code includes. I know nothing about the old .qlgenerator plugins at the source level, so would have no way of telling you how different or not this new API is from that which is now deprecated.

Ok, I saw. I will try to migrate the code on the new system, apparently it does not seem a very complex operation.
Is the new quicklook extension system only valid for catalina? The test plugin I made works on catalina and is seen in the list of extensions while on mojave it does nothing and does not appear in the extensions.

[Nef10]

I had a look at migrating the code over, should not be too complex. I experimented with migrating the https://github.com/whomwah/qlstephen plugin and it was fairly easy. But with the plugins running in a sandbox you cannot just call the highlight tool as the path of the homebrew installation is not allowed to be called. I tried adding the binary to my project but it failed because it calls a dsym. Apparently compiling it so that is does not require the dsym is not easy. The easier solution would probably be to do a link to highlight in one of the allowed path from the sandbox, but this needs to be done manually by the user.

[sbarex]

I'm converted all objective-c code to swift and I have also implemented a switch for light/dark theme.

To works the extension must be sandboxed. But a sandboxed code cannot execute shell process, not event call which highlight!
After many test I have found a solution using a XPC service dedicated to obtain the formatted code. The XPC may not be sanboxed, so it's can run shell command.
I didn't check if a signed sandbox app require a paid developer account, but for now it seems that the extension does not require notarization.

The advanced of extension is that it's embedded inside an app. So in this app is possible to create an interface to customize the extension (choose the theme for example).

Now I need to make more test before relasing the code.

[sbarex]

I had a look at migrating the code over, should not be too complex. I experimented with migrating the https://github.com/whomwah/qlstephen plugin and it was fairly easy. But with the plugins running in a sandbox you cannot just call the highlight tool as the path of the homebrew installation is not allowed to be called. I tried adding the binary to my project but it failed because it calls a dsym. Apparently compiling it so that is does not require the dsym is not easy. The easier solution would probably be to do a link to highlight in one of the allowed path from the sandbox, but this needs to be done manually by the user.

The solution to embed higlight binary inside the extension is not praticable. colorize.sh call some other command to preprocess some type of files (decompile applescript and java, convert binary plist, …).
And the embedded higligligh should be compiled statically, embedding all required libraries (lua, bootstrap, others?) and I don't know how make a fat binary valid for many macos version.

[Nef10]

I am by no means an expert - I just spend a couple of hours experimenting. At the end I also found XPC mentioned but did not have any time investigating more, maybe I should have mentioned this. I just wanted to share my insights in case in would help anybody, but seem you have already made more progress than I did :)

Feel free to just put the code up, I can and would like to help testing or whatever else is needed

[neslob]

hmm, no concrete idea.
try checking where you installation is mdfind QLColorCode

[gbstan]

@neslob: I see in this thread that @sbarex has reconfigured and recompiled the code. Did you install from brew or from another source?

[gbstan]

This is what mdfind QLColorCode returns:

~/Library/QuickLook/QLColorCode.qlgenerator
/usr/local/Caskroom/qlcolorcode
/Users/guy-bartstan/Library/Group Containers/G78RJ6NLJU.group.at.EternalStorms.Yoink/Documents/YoinkPromisedFiles/ESSYoinkSnippets/90E5772D-1DAE-4106-9489-38EBA14D352F.rtf
/usr/local/var/homebrew/locks/198235097cabb60e6828cae82b14a6c6fe7adc49b834548c14c9f644c4c588c3--QLColorCode.qlgenerator.zip.incomplete.lock
/usr/local/Homebrew/Library/Taps/homebrew/homebrew-cask/Casks/qlcolorcode.rb

[sbarex]

@neslob: I see in this thread that @sbarex has reconfigured and recompiled the code. Did you install from brew or from another source?

My project is not a simple fork of this repository but a different application (which uses the new catalina api for the quicklook extensions) that was inspired by part of this code.

[neslob]

@neslob: I see in this thread that @sbarex has reconfigured and recompiled the code. Did you install from brew or from another source?

Using the original from brew. Just went through all steps it works on my side.

1. brew cask uninstall QLColorCode
2. brew cask install QLColorCode
3. create test file echo -e '#!/bin/bash\n\necho test' > test.sh
4. test preview should fail qlmanage -p -g ~/Library/QuickLook/QLColorCode.qlgenerator -c 'public.shell-script' test.sh
5. list quarantine files xattr -r ~/Library/QuickLook/QL* -d com.apple.quarantine
6. remoave quarantine xattr -r -d com.apple.quarantine ~/Library/QuickLook/QL*
7. preview with color qlmanage -p -g ~/Library/QuickLook/QLColorCode.qlgenerator -c 'public.shell-script' test.sh

[gbstan]

Ok, this opens a qlmanage preview window with the code in colours.

However, the command line throws the following:

qlmanage -p -g ~/Library/QuickLook/QLColorCode.qlgenerator -c 'public.shell-script' test.sh
Testing Quick Look preview with files:
	test.sh
	- force using content type UTI: public.shell-script
	- force using generator at path: ~/Library/QuickLook/QLColorCode.qlgenerator
2019-12-16 14:03:19.330 qlmanage[65179:848209] *** CFMessagePort: bootstrap_register(): failed 1100 (0x44c) 'Permission denied', port = 0x14603, name = 'com.apple.coredrag'
See /usr/include/servers/bootstrap_defs.h for the error codes.
2019-12-16 14:03:19.383 qlmanage[65179:848209] *** CFMessagePort: bootstrap_register(): failed 1100 (0x44c) 'Permission denied', port = 0xd61f, name = 'com.apple.tsm.portname'
See /usr/include/servers/bootstrap_defs.h for the error codes.

What doesn't work is preview using the space bar on a file to quicklook preview it with colours.
If I call the quicklook preview with the space bar on the file selected in finder, I see the code but no colours.

Does this have to do with the directive 'public.shell-script' that you stipulate in the command line?

[gbstan]

Is there a step I am missing to allow quicklook preview of code in colours via spacebar on selected files in the finder?

[gbstan]

Ok. I got it to work. I had to add <string>public.shell-script</string> to the LSItemContentTypes section in the file ~/Library/QuickLook/QLColorCode.qlgenerator/Contents/Info.plist

<key>LSItemContentTypes</key>
			<array>
				<string>public.shell-script</string>
                               ...
                        </array>

This now allows to have colours in quicklook previews for shell scripts. I am missing colours for python (.py), latex (.tex), matlab (.m) and other languages. This would probably require similar additions into the Info.plist file, but I am not sure where to find which additions to make to the Info.plist file.

Any good suggestions?

[sbarex]

For know the UTI of a file do this code in the terminal:
mdls -name kMDItemContentType filaneme.ext
where filename.ext is an existing file.

[gbstan]

Yes, this works (as indicated for another quicklook plugin here).

In summary:

1. brew cask install QLColorCode
2. brew install highlight
3. xattr -d -r com.apple.quarantine ~/Library/QuickLook/QLColorCode.qlgenerator
4. add file_UTI to the LSItemContentTypes section in the file ~/Library/QuickLook/QLColorCode.qlgenerator/Contents/Info.plist where file_UTI is obtained via mdls -name kMDItemContentType filaneme.ext (see here)

Now QLColorCode should work via spacebar (you might need to relaunch the finder).

This indicates that the file ~/Library/QuickLook/QLColorCode.qlgenerator/Contents/Info.plist needs to be updated for Catalina MacOS 10.15(.2) as the file UTI properties seems now to be different from the ones that were recognised on Mojave MacOS 10.14.

Although it is possible to manually modify the Info.plist file, it would be great if an updated and verified Info.plist for Catalina could be made available.

Does anyone know how to create a proper Info.plist for qlcolorcode on Catalina macOS 10.15?

[SomerledDesign]

Thank you for this thread. I performed the above steps and now QLColorCode works with all of my source files (ino,cpp,h,c,cs...)

[fregante]

I found a solution that doesn't require editing files.

Solution

Make sure you follow each step correctly. Please don't leave more unnecessary comments so that new users will see this one.

1. Install the plugin (brew cask install qlcolorcode )
2. Select a supported file. macOS will show a warning like this one.
   • DO NOT CLICK "Move to Trash"
   • Click "Cancel"
   
3. Open System Preferences
4. Visit Security & Privacy
5. Ensure you're in the General tab. You should see a notice regarding this plugin at the bottom:
   • Click "Allow Anyway"
   
6. Select another supported file OR run:
   qlmanage -p /path/to/any/file.js
7. You should see a warning similar to the first one, but with a new button
   • Click "Open" 🎉
   
8. Enjoy QuickLooking highlighted files on Catalina
   

[adamwinn]

Yes, this works (as indicated for another quicklook plugin here).

In summary:

1. `brew cask install QLColorCode`

2. `brew install highlight`

3. `xattr -d -r com.apple.quarantine ~/Library/QuickLook/QLColorCode.qlgenerator`

4. add `file_UTI` to the LSItemContentTypes section in the file `~/Library/QuickLook/QLColorCode.qlgenerator/Contents/Info.plist` where `file_UTI` is obtained via `mdls -name kMDItemContentType filaneme.ext` (see [here](https://github.com/anthonygelibert/QLColorCode/issues/51#issuecomment-566155289))

Now QLColorCode should work via spacebar (you might need to relaunch the finder).

This indicates that the file ~/Library/QuickLook/QLColorCode.qlgenerator/Contents/Info.plist needs to be updated for Catalina MacOS 10.15(.2) as the file UTI properties seems now to be different from the ones that were recognised on Mojave MacOS 10.14.

Although it is possible to manually modify the Info.plist file, it would be great if an updated and verified Info.plist for Catalina could be made available.

Does anyone know how to create a proper Info.plist for qlcolorcode on Catalina macOS 10.15?

Why dont you just create a pull request?

[relikd]

The _CodeSignature/_CodeSignature contain the signature of the files inside the package. The quicklook generator was notarized by the author. This is why it works.

Just adding: No you don't need to notorize the plugin for the _CodeSignature folder. A normal (unpaid) Apple dev account is sufficient. Not sure if it will help with the call of highlight but it might help with other issues.

If you need an example of how to configure the signing, have a look at my QLOPML plugin (which doesn't use notarization).
I've used the com.apple.security.app-sandbox and com.apple.security.files.user-selected.read-only entitlements. Using my personal dev account with "Automatically manage singing" and "Development" signing certificate.

[i0ntempest]

Thanks @gbstan I add a bunch of extensions into Info.plist and it works great, except xml and plist files are still handled by the default system generator, even it should be handled by QLColorCode:

i0ntempest:~ Admin$ qlmanage -m|grep Text
  com.apple.property-list -> /System/Library/QuickLook/Text.qlgenerator (906.2 - loaded)
  org.oasis-open.opendocument.text -> /System/Library/QuickLook/Text.qlgenerator (906.2 - loaded)
  public.rtf -> /System/Library/QuickLook/Text.qlgenerator (906.2 - loaded)
  public.plain-text -> /System/Library/QuickLook/Text.qlgenerator (906.2 - loaded)
  com.apple.rtfd -> /System/Library/QuickLook/Text.qlgenerator (906.2 - loaded)
  public.xml -> /System/Library/QuickLook/Text.qlgenerator (906.2 - loaded)

Any ideas?

[gbstan]

Thanks @gbstan I add a bunch of extensions into Info.plist and it works great, except xml and plist files are still handled by the default system generator, even it should be handled by QLColorCode:

i0ntempest:~ Admin$ qlmanage -m|grep Text
  com.apple.property-list -> /System/Library/QuickLook/Text.qlgenerator (906.2 - loaded)
  org.oasis-open.opendocument.text -> /System/Library/QuickLook/Text.qlgenerator (906.2 - loaded)
  public.rtf -> /System/Library/QuickLook/Text.qlgenerator (906.2 - loaded)
  public.plain-text -> /System/Library/QuickLook/Text.qlgenerator (906.2 - loaded)
  com.apple.rtfd -> /System/Library/QuickLook/Text.qlgenerator (906.2 - loaded)
  public.xml -> /System/Library/QuickLook/Text.qlgenerator (906.2 - loaded)

Any ideas?

I don't really know why this is not dealt with by QLColorCode. Maybe there is an order list for certain files that the OS deals with in priority via its own internal preview? Or, you have certain files that are not captured by the above?

[i0ntempest]

Thanks @gbstan I add a bunch of extensions into Info.plist and it works great, except xml and plist files are still handled by the default system generator, even it should be handled by QLColorCode:

i0ntempest:~ Admin$ qlmanage -m|grep Text
  com.apple.property-list -> /System/Library/QuickLook/Text.qlgenerator (906.2 - loaded)
  org.oasis-open.opendocument.text -> /System/Library/QuickLook/Text.qlgenerator (906.2 - loaded)
  public.rtf -> /System/Library/QuickLook/Text.qlgenerator (906.2 - loaded)
  public.plain-text -> /System/Library/QuickLook/Text.qlgenerator (906.2 - loaded)
  com.apple.rtfd -> /System/Library/QuickLook/Text.qlgenerator (906.2 - loaded)
  public.xml -> /System/Library/QuickLook/Text.qlgenerator (906.2 - loaded)

Any ideas?

I don't really know why this is not dealt with by QLColorCode. Maybe there is an order list for certain files that the OS deals with in priority via its own internal preview? Or, you have certain files that are not captured by the above?

According to what I found online If two or more generators can open the same UTI the order should be:
(Used first) App bundled generators -> ~/L/Q/ -> /L/Q/ -> /S/L/Q/ (Used last)
I have public.xml, com.apple.property-list in the Info.plist of QLColorCode. Weird It's still using the system one. So yea, probably OS takes priority on those files... which sucks ¯_(ツ)_/¯.

[relikd]

@i0ntempest Did you try to restart your mac completely? Maybe that will fix the order. Another thing you can try is add the other types for xml as well:

kMDItemContentTypeTree = (
    "public.xml",
    "public.text",
    "public.data",
    "public.item",
    "public.content"
)

And lastly, did you update Xcode recently? That may have changed the precedence? For me, xml and plist files are handled by Xcode, not Text. Even though my qlmanage output is the same.

[i0ntempest]

@relikd You sure your plists are handled by Xcode? For me the generator in Xcode only handles provision profiles. Also I did all you suggested and still nothing. I even tried removing public.xml and com.apple.property-list from /S/L/Q/Text.qlgenerator. The only way to make it work for me is to temporarily delete /S/L/Q/Text.qlgenerator

[relikd]

does it work if you force the generator?
qlmanage -c public.xml -g ~/Library/QuickLook/QLColorCode.qlgenerator -p ./file.xml

Though I don't know what to do if it works properly. I am assuming you already qlmanage -r && qlmanage -r cache? Last thing you can try is the dyn type for xml: dyn.ah62d4rv4ge81u5pq. Other than that I have no ideas left.

[i0ntempest]

It does work if I force it, but the dyn type does nothing. Guess I'll have to live with it.

[i0ntempest]

I've forked this and added dark mode support and some more. It's more of a programming exercise for me but hopefully it's useful to someone.

[sbarex]

I've forked this and added dark mode support and some more. It's more of a programming exercise for me but hopefully it's useful to someone.

take a look at my repo sbarex/SourceCodeSyntaxHighlight

[kulak]

Removing the quarantine attribute from all files is another solution, to get Quicklook working. No need to change any code.

List attributes
xattr -r ~/Library/QuickLook/QLColorCode.qlgenerator

Delete attribute com.apple.quarantine
xattr -d -r com.apple.quarantine ~/Library/QuickLook/QLColorCode.qlgenerator

Or simply zip files, delete original files and unzip. Works on Windows and Mac.

[poochwashere]

Insanely late to the party but kulak's suggestion worked for me.