Thank you to all for your support as we improved Hook 3.6’s new “hooked” status indicator feature.
In Hook 3.6.1, using Hook’s General preferences tab, you can now configure Hook’s menu bar icon to display a colored badge indicating the number of items hooked to the foreground item. If the number is known to be zero, you will see the default Hook menu bar icon. If the app can’t determine the number of items hooked to the current resource, the badge will display a question mark.
Also, unless you are using macOS 10.13, you will not receive notifications that "Hook.app wants access to control <the foreground app>". Hook will not attempt to show the number of hooks associated with an app that you have not previously given Hook permission to interact with.
Please note that by default, the menu bar icon badge feature is disabled (as in Hook 3.6).
Also, this build improves integration with the classic edition of Evernote. The Reminders app is now excluded from status polling.
Nice update. The hook indicator works correctly in most apps (like OmniFocus or DevonThink). But in Obsidian, I just see a “?”, even when there are existing links to the current file. When I open up the Hook window it shows the existing links, but the menu bar item shows “?”. Is this a bug? FYI I’m using Advanced URI plugin mode.
The third state is also currently encountered with apps that are URL-friendly but that do not support AppleScript for linking. Those are mainly x-callback-url apps. We might be able to provide a hooked-status badge for them in the future.
I’ve added the link. Per the above, we do expect the menu bar icon badge to support x-callback-url apps in the future. It requires extra work and we wanted to get the feature out the door and get some feedback on it. We may update Link-friendly Mac Apps – Hook page so you know. To be clear, we consider apps that are linkable with x-callback-url to be URL-friendly per the Manifesto for Ubiquitous Linking.
Since updating from 3.6 to 3.6.1 with the improved indicator, the status of DevonThink items occasionally stops displaying correctly and instead settles on the 3rd state of “unknown.” Quitting and restarting hook resolves the issue, but there is apparently some recurring issue.
There are certain items that are currently unsupported, such as smart groups. When you see this, would you please invoke Hook’s contextual window . If its status bar shows No linkable item found in DEVONthink, then the menu bar icon is displaying the correct result.
correction, smart groups work in some contexts, like inbox, but not in the smart groups view. Hook’s simply calling the AppleScript. So if the AppleScript returns a valid value, then Hook’s menu bar icon will reflect that.
It’s not smart groups, just an item selected in the main window. Quitting and restarting hook resolves it, but here’s the item with the hook window invoked, and again active after a long pause not updating the toolbar.
The little question mark overlaying the menubar icon is visible almost all the time, and distracting, so I turned it off in Preferences. It’s distracting because it reads as though there’s a problem with Hook. (Some apps use question marks to denote “trouble”.)
Not being a fan of the question mark could you consider providing other options other than the current “use it or do not use it”? I think you had something in an earlier release where the icon seemed to change weight (fatness)?
Here’s a suggestion – since the question mark means Hook isn’t sure if there is a Hook link for the current context (web page or whatever), then not displaying anything is the same result? If there is an icon with a number in it, then Hook definitely knows there is a link. If there is no icon displayed, then Hook does not know if there is a link?
I just continue to find the question mark as really weird UI design. “Hook thinks something exists, but isn’t sure.” I don’t understand why that’s useful. It reads like an error message, but there’s really no error.
I also don’t understand why our choices are between having the question mark persistently appearing (it appears very very frequently for me), on the one hand, and turning off both the question mark and the useful display of the number of items hooked to the current context, on the other hand.
It’s not that Hook thinks something exists; it’s that Hook does know one way or another. It’s that its knowledge is in an indeterminate state. So there is : true, false, unknown. Unknown currently gets a question mark. Under the hood there are two sets of apps for which this shows up: UI-scripted apps and x-callback-url ones; and even URL friendly apps can be in N/A states (e.g., a draft email has no persistent ID: it’s not that nothing is linked to it, it’s that there’s no referent). There’s no way out of Hook’s unknown state for the former type of apps; they would need to provide the required automation. The x-callback-url case we will deal with at a later point.
Once Hook’s badge supports x-callback-url apps, the “?” will also mean: “this app is not URL-friendly” per the Manifesto for Ubiquitous Linking, which we encourage all Hook users to consider signing.
I agree a question mark, while precise, is attention grabbing. And for some that is evidently distracting.
one of the requirements is that the symbol be relatively clear in meaning. Normally a “?” does convey “don’t know”. Maybe there is an icon that better represents that. Another requirement is that it be distinct from the zero case, which we’ve decided would be implicit (no zero). Zero case is actually the most common case,so we feel it deserves the default icon.
We’re open to suggestions about how to display the states. In fact, some of this new design comes from user feedback. And we’ve always avoided using red for this as it would be overkill. We’ll listen to feedback and talk to more users. We’ll also talk to a UI designer to see if they can propose a variant of the logo. Let’s see how it settles.