I think Graham will follow up with more information, but some thoughts here
As long as an application registers its own scheme, the URL returned from getAddress will not be prepended with “hook” scheme.
I think the first order of business will be for the Script tab labels to be updated. The Hook://" label makes it look like the app is specifying a hook:// protocol . The uppercase is meant to signal that this is about Hook (app) not hook:// protocol.
Hook’s modus operandus is that if an application has its own registered (custom) scheme, getAddress should just return the URL with custom scheme. This makes the link work even without Hook. We use hook:// protocol as little as possible.
that is the case. In fact, often Hook is not even the proxy. The user can do “Copy as Link” in Hook, and paste that in a document or note. Then when the user activates it, whatever app is in use will pass the request to the OS. e.g., here is a link to an OmniFocus task via Hook.app.“Copy as Link” : omnifocus:///task/cbA0gCik-Zt. Whether you activate that link in the Hook window or in say TextEdit, it will be passed to OmniFocus (assuming OmniFocus is registered to handle it.)
That is probably quite redundant information for you, but maybe helpful for some of the other readers.
Now finally getting to your point. There is a Favorite apps pane. That currently only has mail apps. Mail apps are there due to a limitation in macOS that Hook allows users to get around. We considered something similar for .txt files. This would override general macOS preferences. We haven’t gone there so far to keep it simple, and again Hook is not always a proxy in activating links. But that pane can in principle have other apps. This explains why we put this in its own pane.
We have a number of significant feature sets to introduce, and a very long list of smaller refinements. So we’re weighing them.