roosterboy Posted December 31, 2014 Share Posted December 31, 2014 How about Alfred setting an environment variable for the keyword used to trigger a workflow (if any)? I can get alfred_workflow_bundleid and alfred_workflow_name but if there are multiple keyword triggers in a workflow, I can't tell which one triggered the action. That could be useful information to have from time to time. Link to comment Share on other sites More sharing options...
vitor Posted December 31, 2014 Share Posted December 31, 2014 Could you give a few examples of how you’d use it? Maybe there’s a different way to go about it, in the meantime. Link to comment Share on other sites More sharing options...
deanishe Posted January 5, 2015 Share Posted January 5, 2015 I often use AppleScript to call back into my workflows (e.g. to jump back up a level or two, or reopen the list of config options after one has been changed). This works okay, but it's fragile because it will cease to work if a user changes a keyword. If there were a way to determine the keyword used, this could be made much more robust. Link to comment Share on other sites More sharing options...
Aviesh Posted March 8, 2020 Share Posted March 8, 2020 +1 Very useful to create conditional execution further on the workflow I'm using applescript to rerun workflows while a keyboard modifier is set and I have multiple keywords activating the workflow so I need to detect them to run them again see here for an example https://github.com/avielsh/alfred-catemoji-workflow Link to comment Share on other sites More sharing options...
Andrew Posted March 9, 2020 Share Posted March 9, 2020 Re-running a workflow based on a keyword is also fragile, as there may be multiple Inputs with the same keyword, and you'd get unexpected results (i.e. multiple workflows running on calling back for that keyword). It's better to use an external trigger wired into the Keyword Input and call back on that instead which takes you directly into the keyword you want by specific identifier. Link to comment Share on other sites More sharing options...
deanishe Posted March 9, 2020 Share Posted March 9, 2020 1 hour ago, Andrew said: It's better to use an external trigger wired into the Keyword Input and call back on that instead which takes you directly into the keyword you want by specific identifier. But that doesn't work with Alfred's history. I appreciate the potential fragility of calling back into a workflow via keyword, but that's a potential problem vs the very real usability issue of External Trigger mode not allowing you to back up or reopen Alfred at where you'd just drilled down to, forcing you to start all over again instead. Link to comment Share on other sites More sharing options...
Andrew Posted March 9, 2020 Share Posted March 9, 2020 8 hours ago, deanishe said: I appreciate the potential fragility of calling back into a workflow via keyword, but that's a potential problem vs the very real usability issue of External Trigger mode not allowing you to back up or reopen Alfred at where you'd just drilled down to, forcing you to start all over again instead. It sounds like we need some way to call a Keyword Input directly from external AppleScript (via some sort of id, and providing an argument). This would allow Alfred to make that Input unique (much like pressing return on the result placeholder for that input, and the other results are removed), while populating the keyword and provided argument for the history. devalias 1 Link to comment Share on other sites More sharing options...
deanishe Posted March 9, 2020 Share Posted March 9, 2020 (edited) 1 hour ago, Andrew said: It sounds like we need some way to call a Keyword Input directly from external AppleScript (via some sort of id, and providing an argument) Well, Script Filters in my case, but that would solve my use case, and setting a variable to the entry point's ID would solve @Aviesh's. More generally, being able to call arbitrary elements by ID instead of having to route control flow through a bunch of Filter or Conditional elements would be helpful. For example, you could show an error message in a Notification from anywhere within the workflow without having to wire everything into the Notification element (though this particular case can also be handled via an External Trigger). Edited March 9, 2020 by deanishe devalias 1 Link to comment Share on other sites More sharing options...
Andrew Posted March 10, 2020 Share Posted March 10, 2020 @deanishe I'll see what's possible for 4.1 deanishe and devalias 2 Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now