It would be very handy to activate/focus an existing browser tab instead of just letting Safari handle opening the linked URL. Safari (at least in 12.1.2), switches to the existing tab as desired, but reloads it. Ideally it would just switch to the existing tab without the reload. An example use case for this would be long web-based documents (Google docs, Dropbox Paper, etc.). When Safari reloads these, the scroll position is lost (in addition to the time wasted finding your previous position in the document, time is also lost waiting for the reload itself to occur). So, yes, this is using Hook beyond just a ālinkerā and also using it as an app switcher.
The desired Safari behavior is achievable through Apple Script but Iām running into trouble getting it to work as a Custom Open Item script.
Is a custom Open Item script possible with browsers? I notice Chrome, Firefox and Safari donāt have this script out-of-the-box, indicating that macOS is handling the call.
If it is possible, what should be used as the Scheme? Iāve tried web, browser, safari and url with no success. (I notice that Apple Mail, Airmail and MailMate all used the email Scheme so I was thinking it might need to be something specific but donāt think Iāve guessed correctly.
For testing purposes, I entered a simple Open Item script that just opens an alert dialog box with a ātestingā string. However I donāt get an alert when opening a linked Safari URL via Hook. Safari just goes ahead and reloads the page in the existing tab (or opens a new tab if it doesnāt exist). It seems like my Open Item script is being bypassed. Any pointers? Thanks in advance!
Thanks for the tips! I didnāt see either of those in the docs, however my custom Open Item script still doesnāt seem to run.
Iām using safariurl which seems unique. It doesnāt appear in any other app under the Scripts tab in Prefs.
Definitely didnāt know this was required. I tried deleting and relinking to a couple of different sites (just to rule out an issue with a certain domain) but I still get the normal Safari loading behavior and not my Applescript alert.
I tried restarting Hook and the apps involved (Safari, Word) as well just in case but no joy. Am I missing anything else? If it helps, hereās a screenshot of my current Safari script setup:
The scheme has to match the URL returned by the Get Address script. If the scheme is safariurl, Get Address needs to return safariurl://whatever.com instead of https://whatever.com
The Get Address script will need to change the scheme of the URL it returns. Try something like this:
tell application "Safari"
set d to first item of documents
set u to URL of d
set AppleScript's text item delimiters to {"://"}
return "safariurl://" & text item 2 of u
end tell
On behalf of CogSci Apps, thank you . While the tool is designed to be helpful for all knowledge workers and higher ed students, we are also particularly determined to ensure that it solves all the āmeta-access problemsā developers face. E.g., Hook can generate links to files that are in repositories (like Git, SVN and Dropbox) that work across users and even if the files are moved to different folders. When I write technical documentation (something I do a lot of here at CogSci Apps), I include Hook links (in Markdown) in the āRelated Documentationā section. I also often include a Hook links folder in my tech docs, so that readers can quickly navigate. and of course you can share links to code as well (which you can include in code comments , emails, etc.) Hookās DB is not encrypted. No ālock inā. We have already announced on this forum that Hook itself will be automatable. We will publish several documents later about how Hook is friendly to developers.
(More generally: Hook really is an example of a tool that is designed to solve problems that we ourselves faced ā as developers and as knowledge workers. In fact, it is part of our longstanding research projects on the meta-access problem (navigating related information). The term meta-access problem comes from my first Cognitive Productivity book. Previous work on āpersonal information managementā had not adequately characterized the problems (e.g., the prominent metaphor in the literature still is curation ā yet clearly whereas some curation/organization is required, people often CANNOT curate/organize, because the info is in shared repositories or on the web.) We will also publish papers about this in human-computer interaction. But I digress.)
Thanks for clearing this up! Your guidance helped me make it work! Iāll clean it up and post in the scripts category (and link to it in this thread) in case anyone else would prefer this behavior as well.
I definitely did not understand the concept from reading the scripting docs several times.
It is confusing the docs have the correct url format (e.g. scheme://document-identifier) but the Scripts dialog in the app shows the format on the Open Item tab: Hook://[scheme]/document-identifer. The Get Address script doesnāt include Hook and :// is in the wrong place.
Overall, it seems it would also help to understand custom scripts if the docs started with a detailed overview of the process Hook uses to link items. E.g. When you press ā+C, Hook calls the Get Address script which must return the url in the formatā¦
Is there a place on the forum we should suggest doc enhancements?
Great question. Iām just starting out with Hook so I donāt have a ton of existing links but if Iād have been using it for awhile, the thought of having to go relink everything involving the app (Safari, in this case) because it now has to use a custom URL scheme, is scary.
There has been mention the roadmap may include some ability to access the Hook database. I wonder if this would allow bulk updates to links of a certain type. Of course, back to your original point, if the custom Open Item script didnāt rely on a custom URL scheme a bulk update wouldnāt even be necessary.
Thanks for the feedback. Iāve added an action in our issue tracking system to improve the documentation in line with your suggestion. We are planning significant updates to match upcoming enhancements of Hook itself.
Thanks for the clarification, @LucB! Iāll definitely add anything I can think of to that category.
@LucB, any thoughts on putting the other topic here (not requiring a custom URL scheme when you just want to change the Open Item behavior) on the roadmap?
In the case of the browser, Iām assuming Hook is just sending the URL to the system to handle opening. It would be amazing if Hook could detect the Open Item script and use that instead of relying only on a custom URL scheme. I realize this would probably require a preference to set the browser youād like Hook to use to open web URLs (assuming it canāt get the default from macOS programmatically) so it could determine the script to use but totally worth it!
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.
. While the tool is designed to be helpful for all knowledge workers and higher ed students, we are also particularly determined to ensure that it solves all the āmeta-access problemsā developers face. E.g., Hook can generate links to files that are in repositories (like Git, SVN and Dropbox) that work across users and even if the files are moved to different folders. When I write technical documentation (something I do a lot of here at CogSci Apps), I include Hook links (in Markdown) in the āRelated Documentationā section. I also often include a Hook links folder in my tech docs, so that readers can quickly navigate. and of course you can share links to code as well (which you can include in code comments , emails, etc.) Hookās DB is not encrypted. No ālock inā. We have already announced on this forum that Hook itself will be automatable. We will publish several documents later about how Hook is friendly to developers.