conda/menuinst

Handle URL protocols

Closed this issue · 0 comments

Checklist

  • I added a descriptive title
  • I searched open requests and couldn't find a duplicate

What is the idea?

Associate a given URL/URI protocol with an application via its shortcut. This is different in each platform:

  • Linux supports it as part of the .desktop metadata. The URL is passed via argv.
    • Tests needed: #119
  • Windows requires registry keys. The URL is passed via argv.
  • macOS requires:
    • some keys in the .app .plist file
    • an event listener in the program being launched.

Notes for macOS

The URL is not passed via argv. Instead an event is emitted, containing the URL. In macOS, we have a C launcher because macOS expects a single identifiable binary inside the .app directory. This cannot be a shell script, because those are executed with a shell outside the app. The C launcher forks and spawns the command (whose main executable should be symlinked inside the app too). This way, macOS ties everything nicely, including the event loop, plus keyboard shortcut menus and more. Without it, the app does launch but it's not as well integrated in the system. Check this thread for more info.

We would need to teach the C launcher to listen to those events, but the Apple APIs are mostly available in Swift and Objective C, so we need to create something. After some research we have found some resources:

@aganders3 has been experimenting with other setups too so we might need change how all this works. More info in #117.

Why is this needed?

Applications often need to be associated with file types and URL protocols to handle special links being clicked on a website (e.g. app store stuff, authentication workflows...).

What should happen?

The associated app should launch with the URL being passed through standard means.

Additional Context

Note, this only covers launching an app with a given URL. If you want an open app to recognize URLs or files being passed, you might need a running service that dispatches to a listener or something, and this is not in the scope of menuinst. We might probably create a general solution for that though? Or maybe something exists.