deanishe

That's what's very fragile. Simulating mouse clicks is basically just blindly clicking a fixed location on the screen. It's up to you to make sure the right application is under the mouse, not under any other windows and in the right mode to begin with. And there's generally no way of telling whether or not it worked from your script.

What you describe sounds like 95+% scripting, tbh, and doesn't really have a whole lot to do with Alfred. I mean, Alfred can launch your scripts via a keyword or a hotkey or even a snippet, but it doesn't provide any tools to help automate clicking buttons or playing playlists because Alfred's a launcher, not an automation toolbox. Unless all your apps have automation APIs, that sounds like it might be quite a fragile workflow and hard to get right.

Yes, you're right. I'd misunderstood what you're script was doing.

I think that's the wrong PID… By the looks of it, that's the parent script that launches the long-running, background one. You need to save the PID of the long-running, background process and check for it in the parent script. If the PID file doesn't exist or contains an invalid PID, the parent script starts the long-running background process. If you do it the normal way, the parent can write the new process's PID to the PID file. As you're asking Alfred to start the process for you, you can't get its PID, so the background script will have to save its own PID to the PID file. Also, because you're starting the background process asynchronously via Alfred, instead of waiting for it, it's possible Alfred will start running your Script Filter again before it starts the other one, leaving you with multiple copies of the background process running anyway.

If you're launching your long-running script from the Script Filter script, you still have the problem of the script being run multiple times. Unless it's your own server the workflow hammers, you should probably still implement some kind of guard or lock to prevent multiple copies running at the same time. A PID file is just a file that a program creates at a known path when it's running and deletes when it exits. It's called a PID file because the program usually writes its PID to the file, so you can easily check if the program really is running (kill -0 <PID>) or has exited but failed to remove its PID file. Most of my workflows have Script Filters that launch longer-running background jobs to fetch data or check for updates. If you're interested this is the API I wrote for doing that, and here's the demo workflow showing how to use it.

Right, so if 1 and 2 should start at the same time, either you Start both via another trigger (Hotkey, Snippet Trigger etc.), or Start script 2 from the same code as 1, being careful to properly background the process and make sure you're only running one copy of 2 at a time (e.g. using a PID file).

Sure. You can create your own workflow and launch it either via a Hotkey or Alfred's File Actions. Use a Hotkey with Argument "Selection in macOS" and/or a File Action. Connect it/them to an "Open File" Action set to open the files in Photoshop.

So what you want to do is: 1. Show something in Alfred, e.g. "fetching data..." 2. Go off to the web and fetch some data 3. Show those data in Alfred Is that right? This whole "concurrency" thing is just the way you think you should do that?

No. Alfred will try to run the workflow for every single character the user enters (unless "Alfred filters results" is used). As for the concurrency issue: 1 and 2 cannot run concurrently because you've connected 2 downstream of 1. That means Alfred won't start 2 until 1 has finished running and the user actions a result. If you want to run two or more elements (Run Script and/or Script Filter) at the same time, they all have to be connected to the same trigger (Hotkey/Snippet Trigger/Keyword etc.) If you want to launch another process in the same script as a Script Filter—and you're not using "Alfred filters results"—you need to have logic in place to ensure it's only run once: as mentioned above, Alfred will typically execute a Script Filter several times as fast as it can, and you could easily end up with 5+ copies of the process running.

This site's interesting, as the search uses a JavaScript list of artists. So here's a workflow that directly searches the list of artists. Much better than an Alfred web search.

You have a typo in the URL. There's an extra apostrophe in the path: It's /'artist-, not /artist-. In any case, that's only going to work if you type the artist's name as lastname-firstname.

No. One or the other. They do the same thing. Alfred won't let you create a Hotkey for that key, so you'll have to use a different app and the AppleScript if you want to bind to a numpad key without a modifier.

What exactly are you trying to achieve? You can't have two scripts send results to a Script Filter, AFAIK. Also, Alfred is (or at least was) a bit finicky about what it considers a finished process. Your process must also close STDOUT and STDERR for Alfred to consider it done. So moving processes to the background with & isn't enough. You also have to redirect STDOUT and STDERR, so Alfred doesn't wait for it to complete.

Workflow with a File Action to create a tree of directories.

No. My post is pretty clear that {var:...} expansion doesn't work in Script boxes and also explains exactly how to read the variables from Python code.