Add support for dynamic and unknown UTI types #87
Comments
|
To add to the set of tested files, here is what happens when you use the LICENSE file in this repo. I also copied it and added |
|
Fun with UTIs Right now the plugin registers itself at the highest point that makes sense in both the physical and functional hierarchies. There is a good case to be made for changing public.content to public.text but that's not a discussion we need to have here. Let's figure out how we can get this plugin working for more files. |
|
Hi, thanks for your work on this. I want to add +1 for yaml support. Fwiw, that has been implemented here but hasn't been updated in quite awhile |
|
@relikd I found this: PrivateLogs Here is a log of running This confirms my suspicion that this is due to macOS setting the kMDItemContentType to a "dyn.*" value. |
|
Thanks for the PrivateLogs link. Yep, I encountered this issue too. Even pre Catalina, in fact even pre Mojave. Just recently I was working on QLOPML on a 10.13 machine. Additionally, I found this blog post very helpful: Analysis of UTIs (had to search a while to find this post again). |
|
If anyone has any details on what the file type list looks like for the "Generic" QuickLook plugin that ships with macOS it might lend a clue. Or possibly, it's just hardcoded as the final fallback. I hope that's not the case. |
|
tl;dr on the dyn.* namespace: |
|
Do you happen to know which of them might be the generic QL plugin? But then I'm not sure why And why QLstephen fails for e.g., the |
|
Also, I tried creating a custom Somehow the UTI is not recognized as being inherited from
So the problem really is, that macOS can't seem to map |
tsdorsey
changed the title
|
I was sent here from #81. I used to have a working qlstephen setup but haven't since Catalina. I have rebooted my machine, |
|
Can you uninstall the brew and try again with https://github.com/whomwah/qlstephen/releases/latest (following the † at least working on files w/o extension. Unknown extensions are known to be broken (see discussion above). |
|
Just did this: $ brew cask uninstall qlstephen
==> Uninstalling Cask qlstephen
==> Backing QuickLook Plugin 'QLStephen.qlgenerator' up to '/usr/local/Caskroom/qlstephen/1.5.1/QLStephen.qlgenerator'.
==> Removing QuickLook Plugin '/Users/philfreo/Library/QuickLook/QLStephen.qlgenerator'.
==> Purging files for version 1.5.1 of Cask qlstephenThen downloaded, unzipped, copied to Then relaunched finder via right-click method.
More debug info: $ qlmanage -m | grep public.data
public.data -> /Users/philfreo/Library/QuickLook/QLStephen.qlgenerator (1.5.1 - loaded)
$ ls -l /Users/philfreo/Library/QuickLook
total 0
drwxr-xr-x 3 philfreo staff 96 Oct 24 2018 DropboxQL.qlgenerator
drwxr-xr-x 3 philfreo staff 96 Feb 4 12:35 QLStephen.qlgenerator
drwxr-xr-x@ 3 philfreo staff 96 Oct 21 2014 WebP.qlgenerator
drwx------ 3 philfreo staff 96 Nov 10 2018 qlImageSize.qlgenerator
$ ls -l /Library/QuickLook
total 0
drwxr-xr-x 3 root wheel 96 Nov 10 2018 Video.qlgenerator
drwxr-xr-x 3 root wheel 96 Sep 15 2018 iWork.qlgenerator |
|
Okay perhaps this is helpful: The files I were trying are reporting mdls [...]/LICENSE
...
kMDItemContentType = "public.unix-executable"
kMDItemContentTypeTree = (
"public.item",
"public.executable",
"public.data",
"public.unix-executable"
)
...I've also got some |
|
seems very strange for a plain text file to be executable. Can you create a new empty file with just "hello world" and save that as
|
|
The LICENSE I happened to be trying did indeed have executable permissions ( But I do have some actual unix executables (e.g. little extension-less shell scripts in a bin/ directory) that I'd like to see working. |
|
I think executable files were never supported by QLStephen. |
|
I've created PR #94 just in case. If we dont want it or there are unforeseen side effects, just say so and I'll delete my fork ;-) |
|
This might be crazy talk, but I'd be happy if qlstephen showed me a text view of any file for which it can't otherwise distinguish. (At least the first few kilobytes of larger files.) Not sure if this is possible. |
|
My current understanding of the issue is that:
Which means, we would need a list of extensions that should be supported by QLStephen. Some plugins will define "Imported Type UTIs". That basically replaces the "unkown"
|
|
So we still don't have a solution ? For now I'm just adding the dyn.foobar entries into the plist |
Sorry people, I've read this tread and still didn't understand what you're doing with those "dyn entries"... Do I need to change something here ? |
|
Ok, so according to the source I references above, I would do the following:
PS. You dont need to remove the extension, you can also right-click and 'Show Package Contents' |
|
Wow, thanks so much for such detailed answer !! It surely helped. Meanwhile I also tried another method(from internet) for quicklook to work (guess it works also without the qlstephen plugin) Register a new file extension via the dummy app :
For the experiment I changed the
|
|
I understand the problem hasn't been fixed yet?
|
|
Execute |
I am trying this solution on macOS 10.15.7, but I get "zsh: command not found: lsregister". Any suggestions? |
I guess its in a non-PATH. You can created a symlink or use the full path instead: lsregister@ -> /System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister |
This is a feature to address Issue whomwah#87: "Add support for dynamic and unknown UTI types": whomwah#87 In macOS 10.14(?) and later, QLStephen doesn't appear to work for text-based files that have a filename extension that is unclaimed by any app or bundle present on their system. For example, if no application or bundle on the system claims the “.leaf” filename extension, and assuming they are text files, QLStephen won’t be used to render the text. One way to solve this might be to include a default list of filename extensions that we’d define as text. However, this could be problematic as one person’s `.map` file could be text while another’s could be binary. The default list could also conflict with other apps on the user’s system who do define these filename extensions differently. The solution I came up with is based on the assumption that only the end-user is going to know what filename extensions they come across and whether those files are text-based or not. It uses 2 different apps: 1. `QLStephen.app`: the primary app you interact with. It holds a list of the filename extensions that you've mapped to being treated as text. To map a particular filename extension to be treated as text, we declare that it conforms to “public.plain-text”. By doing so, we then allow the system’s built-in text quicklook plugin to be used to preview the contents. To implement these file mappings on the system, QLStephen.app uses a second application, “QLStephen Dummy.app”, in which the mappings are declared in the `UTExportedTypeDeclarations` of its Info.plist file. QLStephen.app also adds a Service so that you can right-click/control-click on any file in the Finder, and choose “Quick Look with QLStephen ✅” (yes, this is a bit misleading, I guess). This automatically opens it in QLStephen.app, and if it’s found to be text-based, is added to the list of file extension mappings. Then, after updating the dummy app, you can deselect and then reselect the file in the Finder to preview its contents as text. 2. `QLStephen Dummy.app`: This app is created in the ~/Applications/ folder. As mentioned previously, this is a dummy app that declares the file extension mappings in its ‘UTExportedTypeDeclarations` key in its Info.plist file. After modifying the Info.plist of the installed app, it is codesigned to run locally. Some notes/known issues: • Despite having a “Kind” column for you to fill out a file extension’s description, it appears the Finder will always refer to the kind as “Plain Text Document”. • There are some filename extensions that still won’t preview even though they are text-based: `.css` files and `.strings` files are 2 examples I’ve encountered.
|
So, I've come up with what I think might be a workable solution, though I'm looking for thoughts and feedback on it. Rather than having to worry about generating The solution I came up with is based on the assumption that only the end-user is going to know what filename extensions they come across and whether those files are text-based or not. It uses 2 different apps:
To be clear, these 2 apps exist separately from the QuickLook plugin which is still installed into Some notes/known issues:
I have a A link to a compiled and signed binary: https://markdouma.com/developer/QLStephen.zip |
|
As another solution, I wrote a Fish script that automatically detect the UTI type of a given file and append the function ql
set type (mdls -name kMDItemContentType $argv[1] | sed -n 's/^kMDItemContentType = \"\(.*\)\"$/\1/p')
echo $type
plutil -insert CFBundleDocumentTypes.0.LSItemContentTypes.0 -string $type ~/Library/QuickLook/QLStephen.qlgenerator/Contents/Info.plist
qlmanage -r
endUsage for Fish shell: |
|
To summarize the current workaround, below are instructions to quick look a given file or file type ( This was tested on macOS Big Sur 11.3 Terminal (zsh).
|
Works fine, thanks! Note: command |
|
@NSGod Should be possible to merge those into one app right? |
Granted, I can sometimes come up with solutions that tend to be overly complex. |
…lves whomwah#87 So cheaply pretending to be a QLGenerator from Apple seems to be the way to make Quick Look use QLStephen also for UTIs with direct, indirect, explicit and implicit (for dynamic UTIs) conformance to UTI registered for it. If this is the fix, I can only remember that most used language in programming is profanity.
|
After several evenings I've stumbled upon a fix and would appreciate a confirmation. First to showcase the problem:
To test checkout extensions-problem-showcase and run Fix: If confirmed #135 is the fix unless someone has a better idea |
|
For anyone wanting the bash/zsh version of the fish function posted by @xupefei ql() {
set type (mdls -name kMDItemContentType $argv[1] | sed -n 's/^kMDItemContentType = \"\(.*\)\"$/\1/p')
echo $type
plutil -insert CFBundleDocumentTypes.0.LSItemContentTypes.0 -string $type ~/Library/QuickLook/QLStephen.qlgenerator/Contents/Info.plist
qlmanage -r
}Add it to your |
|
If you're getting a "bad pattern" error in ZSH, here's a different version of @jasonm23's script: ql() {
local type=$(mdls -name kMDItemContentType $argv[1] | sed -n 's/^kMDItemContentType = \"\(.*\)\"$/\1/p')
echo $type
plutil -insert CFBundleDocumentTypes.0.LSItemContentTypes.0 -string $type ~/Library/QuickLook/QLStephen.qlgenerator/Contents/Info.plist
qlmanage -r
}
|
I get a lot of plain text files with various extensions such as
.1or.incand currently they only show the icon in QuickLook. Looking at one such file withmdlsI see it has a dynamic type. But the content type tree includes public.data. Would it be possible to extend support to ALL filetypes?The text was updated successfully, but these errors were encountered: