deanishe

Add a Run Script with Language = “/bin/zsh” and put pbpaste -Prefer txt in the Script box. That will pass the contents of the clipboard to the following element.

This has already been addressed. Please read the thread.

File Filters. Built-in example workflows. Look at Examples > Simple Folder Search.

https://github.com/deanishe/awgo/wiki/Catalina

Don't use my version, use the official one: it supports Vivaldi now. If it doesn’t work, you need to check Alfred’s workflow debugger for error messages when you run vivaldi-profiles.

You're talking about Keyword inputs vs Script Filters. If your workflow is run via a Keyword, Alfred doesn't run anything until the user hits ↩ to "enter" the workflow proper. Script Filters, on the other hand, are run as soon as their keyword is matched, and their results are shown inline. You'd need to replace Keywords with Script Filters. Exactly how depends on the individual workflow, but writing code will be required in almost all cases.

What do you mean? "Not appropriately" isn't a good description of what's going wrong. At a guess, I'd say you need to add some short delays between your actions to give the applications you're firing keystrokes at enough time to react before the next one. Don't use Run NSAppleScript. Use a regular Run Script with Language = "/usr/bin/osascript (AppleScript)". Run NSAppleScript behaves unpredictably. Replacing it with a Run Script fixes a lot of non-working AppleScripts.

You still have to use sudo, i.e. run sudo pmset, not just pmset.

Yes. If you give multiple searches the same keyword, Alfred runs both and merges the results. You can do that with a File Filter. Just make sure to set it to search file contents, not just name.

From your description (different monitor = different coords), it sounds like your coords are relative to the screen corner, not the corner of Safari's window.

Yeah, would be a powerful feature.

You have comma set as the decimal separator. All of the things you're calling "bad" are a direct result of your configuration. If comma is the decimal separator, then 10,000 is 10, and 10,000.01 is nonsense.

It sounds like it would make more sense to simulate the click relative to the Safari window, not the whole screen.

No. Drag-and-drop is fundamentally a monkey-with-a-mouse action. I believe it's possible to simulate, but you're going to find it very difficult to tell your script what it should drag without putting the mouse pointer over it… Try to find an API for doing whatever it is that drag-and-drop does in the application.

No. The important thing is to ask Alfred to install the workflow itself, and let it worry about all of that. The simplest and best way to distribute workflows is as .alfredworkflow files. Then all you have to worry about is identifying a newer version and downloading it. Alfred takes care of the rest. Anything else is a bit silly. Updating is difficult to do properly, sucks if you don't do it properly, and it's important to keep your update code as simple as possible because your primary bugfix mechanism is a really bad place to have bugs.

Hi @hitzhangjie, welcome to the forum. Snippet Triggers don't work with {snippet:...}, only regular snippets. In the future, could you upload your workflow and post a link to it, not screenshots and code snippets?

There are a whole bunch of characters that aren't allowed in URLs, including spaces. They need to be converted to a URL-friendly format (e.g. by replacing spaces with + signs), and you can't do that (easily) in AppleScript. Put this script in a Run Script box with Language = "/usr/bin/osascript (JavaScript)" and "with input as argv": function run(argv) { // query is first command-line argument let query = argv[0] + ' meaning' // escape spaces and other characters not allowed in URLs let url = 'https://www.google.mx/search?q=' + encodeURIComponent(query) // open a new browser window with search URL const edge = Application('Microsoft Edge') edge.activate() // bring Edge to the front let win = edge.Window().make() win.tabs[0].url = url } Note: I don’t have Microsoft Edge to test this with, but it works in Chrome. You could probably also use the --new-window http://... command-line flag to the Edge binary, but you’d still need to properly encode the URL.

Yeah, I read that, too. Of course, I'm just getting ready to upgrade to Big Sur now it's as stable as it's going to get… Everything I've read is about call speed, but the main issue in my workflows has always been "connecting" to the app to begin with. Issuing commands is extremely rapid in comparison. If "time to first call" has improved similarly, that's fantastic. I wrote a benchmark script to test bundling set configuration calls to Alfred vs making separate calls, and each call only takes ~0.01 seconds on my machine, but there’s ~0.1s overhead to each tell application ..., which is a long time in workflow land. I'd love to see the results of the benchmark on a Monterey machine.

I think you have the wrong mental model of how it works. External Triggers are one-way, fire-and-forget. In some circumstances, you'll get an error if you try to call an External Trigger that doesn't actually exist (in others, you won't), but that's it. You can't get anything back. The call doesn't even wait for the workflow to run before returning. So the only way workflow A can get something from workflow B is if B provides a way for A to tell it to call A back with the data. Or write it to somewhere A can read it. My Firefox workflow implements both of these methods so other workflows can call it to get info about the active Firefox tab. The way Vítor suggests is much easier, but it can be improved on by monitoring the clipboard for changes instead of just waiting for a bit and hoping. Put that script in workflow B and edit it to run workflow A (instead of simulating ⌘C). It will wait till A changes the clipboard, then continue.

Nobody (on the forum) really knows, hence the vague description. The main difference between Run NSAppleScript and a regular Run Script is that Alfred runs the former in its own process while the latter is run as a separate subprocess. As a result, Run NSAppleScript blocks Alfred, which Run Script doesn't (in addition to the weirdness). That's reason enough not to use Run NSAppleScript. It’s only there for backwards compatibility, I believe. It is slightly faster, but AppleScript is so slow anyway that the difference isn’t noticeable.

The regexes are getting pretty hairy now. I wonder if it might not be more manageable to split identification of code messages (i.e. check for words like "code", "2FA" etc.) from the actual extraction of the codes?

Do you have links to the workflows?

And what did the logs say? Are you getting an error message in Alfred’s workflow debugger? We certainly have no idea what's going on on your Mac, and we can't help you if you don't give us more information than "X is crashing".

It's a bit mysterious, but easy enough once you know how. You have to grab and drag the bar half a centimetre to the right of the preview window (you can't see it, but my mouse is over the green-ish bar):

Probably not so straightforward because it uses sudo, which means you have to enter your password to run the command. The simple solution is to use AppleScript’s do shell script "..." with administrator privileges, which will pop up the standard macOS “Enter your password” dialog. (Every time ) The better, but slightly more complex way is to edit the sudoers file to allow your user account to execute those commands without entering your password (though you still need to use sudo). You might, for example, put skynet ALL=(ALL) NOPASSWD: /usr/bin/pmset in /etc/sudoers.d/pmset to allow user skynet to run pmset without entering their password (you still have to use sudo; it just won’t ask for a password). (Don’t edit any sudoers files by hand! Always use visudo, which guarantees the syntax is correct. Otherwise, if you screw it up, you might no longer be able to get the administrator privileges you need to fix it.)