Open exekutive opened 2 years ago
I do have the same Problem.
I have two instances of the software KiCAD. When I save a file with KiCAD 7 I can no longer open it with the old version.
So I want to open all those files with the old version by default and only some projects I will open explicitly with KiCAD7.
So I looked up the filetype with my alias:
alias filetype="mdls -name kMDItemContentType -name kMDItemContentTypeTree -name kMDItemKind"
filetype *.kicad_pro
kMDItemContentType = "dyn.ah62d4rv4ge8004pdqfwf86dwr6"
kMDItemContentTypeTree = (
"public.item",
"dyn.ah62d4rv4ge8004pdqfwf86dwr6",
"public.data"
)
kMDItemKind = "kicad project files"
So the utility knows that it's a kicad project file but still there is no way for me to assign this type to a specific application.
If there was a way to add those dyn
entries I would be very glad and I guess @exekutive would be too =)
Thanks a lot for looking into this and giving us a tool to work around one of macOS most annoying issues (IMHO).
I have expressly disabled dynamic UTIs because I'm not sure exactly how dynamic they are and if they can be trusted at all or not. I might take a look into this eventually but it's not currently a big priority. Mostly I've been experimenting with converting the app to the newe APIs and SwiftUI.
I have expressly disabled dynamic UTIs because I'm not sure exactly how dynamic they are and if they can be trusted at all or not. I might take a look into this eventually but it's not currently a big priority. Mostly I've been experimenting with converting the app to the newe APIs and SwiftUI.
Hey, I just wanted to post here to say that it seems like dynamic UTIs are in fact a relatively stable format: https://stackoverflow.com/a/16957310/14436105
Those answers/resources are slightly older, but I would guess that it's generally forward-compatible even if the format was updated (and, the linked gist appears to still work today for at least a handful of UTIs from my Mac running Sonoma).
At worst, I'd imagine that a handler would just not be used if it were set for a dynamic UTI that no longer matched a file, which seems like a fairly small caveat.
FWIW the command-line app already seems to handle these fine for setting handlers:
$ open ~/Documents/xterm-256color-italic.terminfo
No application knows how to open URL file:///Users/ianchamberlain/Documents/xterm-256color-italic.terminfo (Error Domain=NSOSStatusErrorDomain Code=-10814 "kLSApplicationNotFoundErr: E.g. no application claims the file" UserInfo={_LSLine=1741, _LSFunction=runEvaluator}).
$ swda setHandler --UTI "dyn.ah62d4rv4ge81k3pwrzy063xt" --app ~/Applications/Visual\ Studio\ Code.app
SwiftDefaultApps SUCCESS: Default handler has succesfully changed to com.microsoft.VSCode
$ open ~/Documents/xterm-256color-italic.terminfo
$ # it opened in VSCode!
Getting handlers, on the other hand does not work, unless you know the UTI ahead of time:
$ swda getUTIs | grep -i dyn
com.microsoft.windows-dynamic-link-library /Users/ianchamberlain/Applications/Cutter.app
$ swda getHandler --UTI "dyn.ah62d4rv4ge81k3pwrzy063xt"
/Users/ianchamberlain/Applications/Visual Studio Code.app
Since these are dynamic, any UI that would handle them for setting would probably need to support dropping a file or something like that to figure out what the dynamic UTI should be - for displaying them, maybe the code I linked above would be useful just to parse out some basic details or something. As for swda getUTIs
, maybe it's just a matter of filtering differently? https://github.com/Lord-Kamina/SwiftDefaultApps/blob/4672a7f028f776697ebd25ac640342f3a497e924/Sources/Common%20Sources/LSWrappers.swift#L472
I'm guessing based on the README that the priority lately has still been updating to newer APIs and stuff so this hasn't been a focus, but just thought I'd leave this in case it's useful information!
Thanks for this app, it's very useful even with only partial dynamic UTI support!
the UTI of my file is 'dyn.ah62d4rv4ge8063xt' It does not show up in the UTI prefpane