-
Notifications
You must be signed in to change notification settings - Fork 161
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Trouble with Extensions in OS X Catalina #86
Comments
I'm on Mojave and I experience this as well. |
I'm unable to preview text files with arbitrary extensions in Catalina as well. My troubleshooting skills have not turned up the exact reason why it fails... so I haven't figured out any way of working around it. It would be lovely is someone with deeper knowledge of macOS would explain what's going wrong. |
I continue to have the same symptoms. I'm adding some details in case it will trigger any ideas in anyone to offer suggestions.
The file metadata is "normal", I think, for an unregistered extension:
According to issue 23: Is qlstephen blacklisted? I don't think so. It's just an *.out file, and the same issue applies to all my text files with non-standard extensions. Is anything competing with QLStephen? I don't think so. QLStephen owns public.data, and no other plug-in claims it.
But this command only gives me the classic useless preview: Forcing QuickLook to use QLStephen works just fine:
Do those permissions issues matter? I don't see how they could matter, since the Quick Look works in this case... but I included them in case they are a problem. Likewise, simply forcing the UTI works as well: But I have no idea how to get it working from Finder. So... any ideas about what's missing in my environment? It's killing me. |
@mdahlman I have observed the same on my machine. From all of the tests, I would say the workflow of Quick Look is as follows: Quick Look will look for any suitable qlgenerator with the "specific identifier" (like "dyn.*", "public.jpeg"). If no qlgenerator is found, then Quick Look will search for a qlgenerator again using the parent type of the file:
If this is not a bug, I would say it is designed yo enchance the security. Before 10.15, a qlgenerator that handles |
This should be fixed in 1.5.1 |
@tsdorsey, you are a hero! A giant among men. A king amongst kings. A restorer of faith in the power of humanity to collectively overcome obstacles like little preview windows that don't work well. |
With version 1.5.1, I am still not able to preview a file if it has a random extension. An example:
QLStephen info:
Seems Quick Look still didn't use |
I've been using this great plugin for a long time, thanks so much!
I just upgraded to OS X Catalina and I am having the following issue. I was not having this issue 2 days ago, before I upgraded the OS.
I have many text files that I have generated and I have given some file extension (say for example .gt but the problem occurs for a number of different extensions). Prior to the OS upgrade, I could QL those files just fine. But now all I see when I activate QL is a generic file icon rather than a preview.
If I take one of those files and remove the extension (or change it to .txt), QL generates a preview no problem.
I've tried reinstalling QLStephen two ways. (1) using homebrew, and (2) by downloading the latest version and copying the QLStephen.qlgenerator directory to /Library/QuickLook/. Then I run 'qlmange -r' but no luck. In my ~/Library/ directory, there is no QuickLook folder/ and I ran a find command in the terminal to see if OS X Catalina is hiding a Quicklook directory somewhere else, but I did not see one.
If I run
'mdls -name lKMItemContentType <file name.gt>
The output is
lKMItemContentType = (null)
Same thing if the file extension is removed, or changed to .txt
If I run
qlmanage -m | grep public
The result is:
If I force qlmanage to use the QLStephen.qlgenerator:
qlmanage -g /Library/QuickLook/QLStephen.qlgenerator -c public.plain-text -p <file name>
I see a preview. It also works if i run the command above with -c public.data.
Any ideas?
The text was updated successfully, but these errors were encountered: