Skip to content
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

Protocol handlers on Mac #138

Open
slipher opened this issue Oct 21, 2024 · 0 comments
Open

Protocol handlers on Mac #138

slipher opened this issue Oct 21, 2024 · 0 comments

Comments

@slipher
Copy link
Contributor

slipher commented Oct 21, 2024

I just found out our Unvanquished app (Daemon, not the updater) has entries in Info.plist that allow it to be automatically be registered for the unv:// protocol. But how it work a mess. Launch Services quite eagerly adds applications to its database under various circumstances and tracks them across moves. For example, in the updater install path ~/Games/Unvanquished, all of Unvanquished.app, updater.app, and updater.app.bak(!) are all registered, judging by /System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -dump. An Unvanquished.app extracted from a 0.55 RC is as well.

In the presence of multiple registered apps for a protocol, I can't find any information on how to set one as the highest priority, nor how to query which one is currently the highest priority using system tools. We can only try opening something, or perhaps write a program using the deprecated LSCopyApplicationURLsForURL.

To start with, we should remove the URL protocol entries from Unvanquished.app and add them to the updater. And fix #106 so there is no .bak one. But still, even assuming we started from a clean slate, there is the original download path of the updater to worry about, before it moves itself. Maybe we'd have to unregister it from the database using lsregister's -u option.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant