-
Notifications
You must be signed in to change notification settings - Fork 0
Open Questions
There's a good number of issues I've run across which I've made no progress on solving. Please help. You're welcome to file an issue on this repo with suggestions.
-
The manpage for 'open' says it can pass URLs to programs. Yet I can't get "open -a MyApp https://google.com" to work at all. I've added a "Service" to the Info.plist with type "public.url", and given it an @objc method in the NSApplicationDelegate. It crashes with some appleevents junk on the call stack, and no indication of what I'm doing wrong, or how to fix it.
Then again, some of the "EXAMPLES" on that manpage don't work, so maybe it's just broken.
Possibly related: when Apple's programs (like Safari) pass URLs, they always pass it as a plain string, not a URL object. The only way to tell if a URL was dropped on you is to accept strings, try to parse the string, and see if it looks like a URL you want to accept. You can select any old text (like the google URL above) and drag it to the desktop, and the Finder will go fetch it as a URL and save a copy as a compressed .webloc archive.
Update: Safari cheats?
-
Spotlight queries often seem to fail. The documentation implies that wildcard chars (
*
?
) can appear anywhere, but they don't seem to work.For example, I created a file called "a.b.c" in my Downloads folder. These work:
mdfind -onlyin ~/Downloads/ "kMDItemFSName == 'a.b.c'"
mdfind -onlyin ~/Downloads/ "kMDItemFSName == '*.b.c'"
mdfind -onlyin ~/Downloads/ "kMDItemFSName == 'a*b.c'"
These do not:
mdfind -onlyin ~/Downloads/ "kMDItemFSName == 'a?b.c'"
mdfind -onlyin ~/Downloads/ "kMDItemFSName == 'a.*b.c'"
mdfind -onlyin ~/Downloads/ "kMDItemFSName == 'a.*.c'"
mdfind -onlyin ~/Downloads/ "kMDItemFSName == '*.*.c'"
mdfind -onlyin ~/Downloads/ "kMDItemFSName == '?.b.c'"
Is there a way to reliably run spotlight queries on filenames?
-
I was led to believe that setting
ITSAppUsesNonExemptEncryption
in my Info.plist would bypass needing to answer the sequence of questions about encryption for every upload. It doesn't, though. What's this key good for, and is there any way to answer these questions just once and have it stick? -
URL's
resolvingSymlinksInPath
intentionally fails for system directories. Is there a public interface which works? -
accessibilityFocusedUIElement says to return nil, but it's type
Any
. You can't seem to add Objective-C categories to Swift classes, either. Is there any way to add accessibility to a Mac application written in Swift? -
When exactly should we use "generic" versus "internet" Keychain items? Only "internet" items have service/port/etc (though the service list is far too short to be of any use, and no modern system is declaring a FourCC for their service). Random people on the internet are full of guesses. One person said "internet" items are meant only for Safari (though that seem to conflict with most of the available service types). One person said "generic" items can't be shared between apps (which is trivially false). "Internet" items seem slightly more useful, though I'll still need to dump some crucial information in a custom field, so that doesn't entirely help me.
It would be great if I could, for example, log into Postgres in AppOne.app, save my password in the Keychain, and then when I launch AppTwo.app to connect to Postgres, it can re-use that saved authentication. That seems like it should be the point of the Keychain. But the docs don't really provide enough information to guess unambiguously how to store passwords in a reusable way, and no two existing apps I've found (before mine) store data in a compatible way.
- A partial answer?: I got the idea somewhere (an Apple comment on a radar I filed?) that, officially, Keychain items are -- despite their global scope/namespace -- intended only for use by a single application. So sharing your Postgres credentials between AppOne.app and AppTwo.app is not really an intended use case.
- The good: you don't need to research all the ways other apps save credentials in Keychain, and you can use any/all fields (including custom fields) that you want. Just make it work. (Maybe try not to smash the host/URI scheme that other apps have chosen, but from what I can tell, they're all crazy in their own way so it's probably not something you'd do by accident, e.g., Oracle picked "Mysql" with capital-M only.)
- The bad: users don't get to share their credentials between apps. (This would be a "good" if it were intentionally blocked for security reasons, but it's not. What we have here is the worst of both worlds: there's no security wall between apps, and also no detailed spec so apps can reasonably share. It's just a free-for-all.)