deanishe

Alfred 2.6, January 2015. In your Script Filter, click the Run Behaviour button. You can choose whether Alfred should wait for or kill an already running script, and you can choose how long it should wait for user input before executing the script.

Sounds like you may have a buggy program that isn't releasing Secure Input when it quits. If I were you, I'd remove my Login Items and disable Run-at-load Launch Agents, then turn them back on a few at a time to try to find the culprit. If the guilty process has always exited, you could narrow down the list of suspects first by comparing your Login Items & Launch Agents with running processes.

Arguably, the "proper" way to do it is to go ahead and try to create the directory and handle the error if it fails because it's an atomic operation. Checking first for existence and then creating the directory isn't atomic, and it's possible (though extremely unlikely) that another process might create the directory after the check for existence and before the creation call. Hardly relevant in a workflow, but check-then-create is a race condition that has led to exploits. It is, but not unrelated. My decision to use the equivalent of mkdir -p in Alfred-Workflow means that workflows written back before Alfred got environment variables (i.e. when paths had to be hardcoded) still work on Alfred 3 (even if they write their data to the wrong directories). Workflows only doing mkdir broke for anyone who deleted (or didn't have) Alfred 2 directories. (FWIW, it's always tested for the existence of the directory first, too. Privilege escalation via race conditions aren't a big worry for AW.)

To be honest, I always use mkdir -p (or equivalent). It's slower, but only hundredths of a second, and arguably more correct (for example, a workflow with Alfred 2 paths hardcoded will still work on Alfred 3, even though Alfred 2's directories don't exist. If you just use mkdir, it will fail.

Here is a fast(-feeling) way. Instead of waiting for missing images, it handles them in a background process and tells Alfred to re-run the Script Filter after 1 second. This class generates thumbnails, but the principle is the same as caching remote URLs. Generate Alfred results and add any missing images to a queue At the end of your Script Filter, if there's a queue, start a background process to handle it If the background process is running, tell Alfred to re-run the Script Filter in a second Exit Script Filter Obviously, the results come up image-less until the images have been cached, but it keeps the workflow super-responsive, and Alfred 3.2's re-run feature seamlessly reloads the results as the images come in.

Generate an alfred://customsearch/ URL. To see one, double-click on a Web Search and click "Copy URL for sharing". Here's the Custom Search URL for my TheTVDB.com Custom Search: alfred://customsearch/Search%20TheTVDB.com%20for%20%27%7Bquery%7D%27/tv/utf8/nospace/http%3A%2F%2Fthetvdb.com%2F%3Fstring%3D%7Bquery%7D%26searchseriesid%3D%26tab%3Dlistseries%26function%3DSearch To install the search, open the URL (with an Alfred Open URL action or open alfred://customsearch/... etc.)

Try adding a delay 0.3 before do script q in front window to give the new tab more time to activate?

You need to know the bundle ID/paths in any event simply in order to use the directories. Not sure how I feel about Alfred auto-creating them. On the one hand, it'd be handy to workflow authors. On the other, you'd end up with an awful lot of unneeded, empty folders.

Not really. They're my personal scripts, and I just put them out there as a possible help to other people. If I put them in a repo, that implies I want pull requests, issues etc. and I don't.

https://github.com/jcsalterego/pngpaste

Is there an API for Data Detectors (the feature that highlights dates and phone numbers in Mail.app)? Might be an interesting feature if Alfred pre-processed the query with Data Detectors and exposed any parsed results as workflow variables. For example, if the query contains "noon tomorrow", Alfred might set the variable DATETIME to 2017-01-20T00:53+0100 (or similar).

That works. There are a few issues. I can't "fix" the workflow, as it isn't complete (You're using a bunch of variables that don't exist to create the file—in {var:path}/{var:name}.{var:type} only type is always set). So, your first pair of filters are incorrectly configured. You've entered "Only continue if filetype is equal to…". That tests the string "filetype", but you want the variable filetype. Change the filters to read "Only continue if {var:filetype} is equal to…". Now that's changed, you can get to step 2. Your second level "image" Keyword should have the "Argument required" option set. This is where the workflow stops working because, as noted, some of the necessary variables aren't set. name is set along the top branch, but not the bottom. Neither sets path.

That link isn't working for me, either, I'm afraid.

That link isn't working. Vero tried it, too.

I hadn't thought about this before, but now you mention it, having something as broken as Siri connected to Alfred or Terminal is a scary scenario.

Put the workflow in your dropbox, right-click, choose "Copy Dropbox Link" and post it here. That might work better. This is the right place to ask for help, but it's usually not possible to help with a broken workflow without the workflow.

Getting a 403 error. Did Dropbox turn off the Public folder already? I know they were planning to.

You can't click the "Rebuild" button again because the system is already rebuilding the index. This can take several hours (it has to read and analyse almost every single file). On earlier version of OS X, clicking the Spotlight icon in the menubar shows you a progress meter if the index is being rebuilt.

You'll have to upload the actual workflow somewhere (Dropbox?) and post a link, so we can have a look. Can't say much from a screenshot.

Not, really, no. The way Alfred works is that it remembers which result you selected for which query, so when you enter "gd" and select "Search Google Drive" (even though it's keyword is "gdu"), Alfred remembers your choice and boosts that result's ranking for that search query. Select that result for that query a couple of times, and it will be the top result (until you "teach" Alfred to associate "gd" with something else). From Alfred's point of view, what you're doing is saying "'gd' stands for 'Open Google Drive'. No wait, 'gd' stands for 'Search Google Drive'. No wait, it stands for 'Open Google Drive' again" etc. etc. What I'd be tempted to do is replace the two actions with a very simple workflow. Have a single keyword ("gd", natch) with optional argument. Connect that to two Filter utilities. One accepts an empty query and opens the "normal" Google Drive URL, while the other accepts a non-empty query and opens the "search" URL. Did I explain that clearly enough?

Glad you like it. The "Buy me a beer" link in my signature leads to Paypal.

It actually already searches all the dictionaries you have active (i.e. "define" searches all languages). It would be nice to be able to search a specific language, however. The main issue is that if you have, say, an English word and a German word that are spelled the same, Alfred will only show one definition. May or may not be in the language you're looking for.

How's this? Download from here.

Right, you're German. In that case "100 30" might make more sense (space instead of comma), so you can enter decimals (e.g. "2,1 5").

So you want to be able to enter "100,30" and the workflow then sends "100<TAB>" 30 times to the active application? That's straightforward enough to do.