.properties files can't be viewed

[ChrisDeath]

Hi

i already tried a lot but on my Catalina MacOSX i am not able to preview .properties files (normal text file with key=value pairs).
Debuging qlmanage shows me:
Did not find any extension matching content type: <private> and application bundle identifier: (null). with specified path (null) #Remote

And if i do mdls on that file following is shown:

mdls project.properties

kMDItemFSContentChangeDate = (null)
kMDItemFSCreationDate      = (null)
kMDItemFSCreatorCode       = ""
kMDItemFSFinderFlags       = (null)
kMDItemFSHasCustomIcon     = (null)
kMDItemFSInvisible         = 0
kMDItemFSIsExtensionHidden = (null)
kMDItemFSIsStationery      = (null)
kMDItemFSLabel             = (null)
kMDItemFSName              = (null)
kMDItemFSNodeCount         = (null)
kMDItemFSOwnerGroupID      = (null)
kMDItemFSOwnerUserID       = (null)
kMDItemFSSize              = (null)
kMDItemFSTypeCode          = ""

So the usual kMDItemContentType or kMDItemContentTypeTree is completly missing. I totally understand that this can not match public.data.

Any ideas?

[tsdorsey]

Check out the discussion in #87 where we're working to figure this out.

[ChrisDeath]

Are you sure that .properties is a rated as dynamic file type, I mean dyn files are at least marked as such, but the properties files arn't marked as anything :(
Just wondering :)

[tsdorsey]

@ChrisDeath I've updated the title of that issue. It's all the same thing. qlstephen is aimed at being a more sane fallback that then generic quicklook that ships with macOS.

From testing is looks like files that start with a . (hidden files) have no kMDItemContentType at all.

In the end, the "issue" is "how do we register qlstephen to handle any file it can realistically preview before macOS falls back to generic.qlgenerator?"

[ChrisDeath]

Hi again, erm...actually there is a missunderstanding. What i mean are xyz.properties files like you can see in the mdls command. It's just a text file with ending on properties. So it is not hidden or has any special attributs set.

[tsdorsey]

Ah, I missed the full name of the file. Doesn't change the rest of my answer though.

Whatever is causing the kMDItemContentType to be missing isn't the issue because I don't think we can change that. The solution will be in finding a way to register the plugin to handle a wider range of inputs. In the end macOS is responsible for choosing the plugin when you hit and we want to inform the OS that we can handle X (whatever X happens to be).