Closed nikitavoloboev closed 7 years ago
Save your script as an application and point the workflow at that.
How do I get the path that your script filter gets to pass into the Automator workflow?
I have this automator applescript that I save save as .app :
Since {query} is Alfred's way of passing input, I can't find a way to do the same in Automator.
Found this. But then it seems that I can't pass anything to it if I save it to .app
Thank you for any help.
Niki, please read errors before posting them.
That dialog says your script won't get any input when run inside Automator.
Yeah but I tried it outside too and it didn't work. :(
This is the applescript I had. I think I know what the problem is though as "cd " & input does not expand input, I am trying to find a way how to do it correctly but to no avail.
on run {input, parameters}
tell application "iTerm"
if exists window 1 then
tell current window
tell current session to write text "cd " & input
end tell
else
create window with default profile
tell current window
tell current session to write text "cd " & input
end tell
end if
end tell
tell application "System Events"
if frontmost of process "iTerm2" is false then key code 13 using {option down, control down, shift down, command down}
end tell
Running it outside just says this :
Which is not very helpful. :(
Which is not very helpful
Why don't you try reading the first screenshot you posted? It tells you exactly how to run the script in Automator. And when you've done that, pay attention to the data types. You can't just add a list of HFS paths to a shell command and expect it to work.
Closing as unrelated to the workflow.
This script worked for me
on run {input, parameters}
set cmdStr to "cd " & (POSIX path of input)
tell application "iTerm"
if exists window 1 then
tell current window
tell current session to write text cmdStr
end tell
else
create window with default profile
tell current window
tell current session to write text cmdStr
end tell
end if
end tell
But you probably already knew that. Thanks for the pointers, this is really cool to see it work.
I have one issue with the above solution and that is that there is a certain (~ 2) seconds delay when activating this applescript. I am not sure if it's because it is calling the Automator application which contains this Applescript or the Applescript itself.
I have saved the Applescript as an app as you proposed and then call it on a modifier keypress:
{
"__workflow_last_version": "2.1.2",
"app_alt": "cdToiTerm",
"app_cmd": "Finder",
"app_shift": "Tower",
"app_fn": "Safari",
"app_default": "Sublime Text",
"app_ctrl": "Visual Studio Code",
Would it perhaps be possible to call Applescript code directly so that Alfred Repos can support it? Or that is not the reason that causes this delay?
Ideally I wish it would activate as fast as this workflow. So it writes the path to the iTerm window immediately upon activating.
Here is the cdToiTerm
app that contains the above mentioned Applescript I am calling.
Thank you a lot for any help on this.
I am not sure if it's because it is calling the Automator application which contains this Applescript or the Applescript itself.
Well why don't you try and figure that out for yourself before asking me to spend my evening adding features to my workflow?
Ideally I wish it would activate as fast as this workflow.
It can't. I'll leave it up to you to figure out why.
I ran the Applescript from Keyboard Maestro like so:
And there it is instant. So the 'issue' is with the workflow.
Will try to add Applescript support to the workflow if only for myself. I looked at the code and I think I can do it.
One advice I can give that I think would be really useful to people who want to contribute to your workflows is letting users know what the best approach for modifying the workflow is. I try to do it like this.
For this workflow, what I do now is modify on the code internally to the workflow but I am not sure if that is the best approach. Another approach would probably be me cloning this repo, then changing info.plist key
to something like net.deanishe.alfred-git-repos.dev
, then symlinking the workflow with your script and working on that. Again I am not sure what the 'best' way is but I guess that would be the right way to do it.
And there it is instant. So the 'issue' is with the workflow.
No, the issue is with you. Compare:
Keyboard Maestro Script
-----------------------
Running application (Keyboard Maestro) -> script in memory -> run it.
Alfred-Repos
------------
Running application (Alfred) -> launch workflow -> load settings and look up app -> Call `open` to run app -> find application on disk -> launch Automator wrapper app -> load script from disk -> run it.
This is exactly the same as the silly "Searchio! is slower than Hammerspoon" issue you posted.
I was thinking as a hack I can capture one of the mod keys. And then filter on the mod keys in Alfred editor and then run the Applescript from there. Same as with my Folder search workflow. Wouldn't this work?
So not only do I pass the query, but I also pass a variable with the mod key. And if mod key is alt
it will activate Applescript.
Wouldn't this work?
I don't know. I've no idea what happens when a Script Filter defines modifiers in its feedback but there's also an action assigned to that modifier in Alfred's UI.
Oh wow. This actually solves it.
This works in case you want the same functionality.
Thank you very much @deanishe
in case you want the same functionality
No. I don't store the applications in the settings file and run them via Python for no reason.
I would like to run this Applescript when fn modifier key is held down and result is picked.
This will cd to the path of the git project from my current iTerm tab.
It would be amazing if it would be possible to add this as it will save me so much time. Thank you.