open the Hook GUI on the folder I’m pointing too (not on the .hook file)
For example, I have a sample_project.hook file that points to the sample_project_directory directory. When I invoke my workflow:
a finder window pointing to sample_project_directory is opened
the Hook GUI on sample_project_directory is opened, and I can get hold of my project resources / OF tasks / Curio folder …
To do the second thing, right now, I’m using @ttscoff 's Hook CLI, and invoking (in Alfred, where $query contains the path to the sample_project_directory: /usr/local/bin/hook open "$(cat "$query")"
Unfortunately it seems the CLI is excrutiatingly slow on my system - 4 to 5 seconds. I’ve tested it in Terminal and I get the same result, so it’s not an issue with Alfred itself. Does anyone know:
is there a reason for the CLI to be so slow
is there any faster way to invoke the GUI (Hook applescript?)
Well the issue here is that i’m doing all of this within a bash script embedded in an Alfred workflow. I guess if push comes to shove I could bundle all of this in a KM macro, which I’d call from Alfred.
I could go all Rube Goldberg on it, of course. But I wanted a little more finesse, maybe
The CLI relies on AppleScript, and AppleScript is slow. It’s not just Hook’s AppleScript, either. I’ve been working on an automation app called Bunch that allows user-created AppleScript’s to run and the delays and thread blocking that happens can be excruciating. I should talk to Daniel Jalkut (who makes FastScripts) and see if he has any tips for speeding up execution, though I’m not sure if any of it would apply to a CLI that’s essentially a shell script calling out to AppleScript.
Hey @ttscoff ! Thanks for taking the time to answer - I use bunch as well, and yes, i’ve noticed the delays as well. So I guess maybe the keypress simulation is the best way to go.
I guess I could also figure out how to call the Apple Script directly - Alfred gives me the option to run Apple Script. Another sunday rabbit hole!
Optimizing hook’s API execution is high on our priority list. We made some improvements last summer but we obviously need to go further. This almost made it into 2.3 (next feature-full release). It is now slated for the next one. It’s a high priority for us because we are keen on enabling an ecosystem of automations and apps to work around Hook (including our own extras/“goodies”).
Hook maintains a database of bookmarks to your most valuable information, hence clearly users need the API calls to return super fast, as if in the app itself.
That would be great.
Another thing that I had to scratch my head was the creating of .hook files by script.
I ended up getting the hook link itself from the script, and then cobbling together a text file with the hook inside and a .hook extension. Not sure it’s very orthodox, but it seems to work…
