vitor

Keyword Input → System Commands Action (Quit All Apps) → Launch Apps and Files Action.

Don’t be surprised. The reason is simple: I’ll stop the quote there, but @deanishe’s full post is spot-on. We’ve been telling you to let go of AppleScript for a reason. Its syntax tries to solve the wrong problem. Looking like written english doesn’t make it simpler, because it’s as rigid as any other language. AppleScript deviates from other languages (making it harder to pick up) and gives you nothing in return. The fact that it can be used to interface with GUI apps has nothing to do with the language itself; they could’ve chosen any other language to give you that ability, and eventually they did (JavaScript). You seem to have this notion that AppleScript is ground zero, a simple language that if you can’t grok you won’t be able to move on to better things. That is absolutely wrong and you’re crippling your own progress. Not sure how to make that clearer. You keep insisting on using AppleScript and we’ll keep insisting you get out of it. Because you keep clinging to AppleScript. By continuing to do so, you’re wasting your time, because whatever you’re learning isn’t easily transferable, and you’re already feeling that. Invest in something else. It doesn’t really matter which language, as long as it’s relatively popular. Being popular means more people rely on it, so more people make tools and libraries to improve their usage of the language and more people discuss it which means you have more resources to learn, understand, and fix your problems. It also means it’s more likely to share concepts with other programming languages. Learn a decent language, and your knowledge will be transferable.

Unfortunately, JXA’s utf-8 support isn’t great either, at least when reading files (note the case here). You have to use the Objective-C bridge to get accurate results. I’m guessing no one works on JXA or AppleScript, at Apple. A single engineer working full-time on these could have fixed most bugs and made them better languages.

Because presumably that sound isn’t available to every app. Alfred’s sounds are the ones made available in /System/Library/Sounds. I’ve made a Workflow long ago to help choose between those. I might release it; it needs a README and an icon to be ready.

Welcome @millerstevew, Have you checked if the contact’s names themselves have spaces in them, in the Contacts app?

When you do cp -a /Users/, the shell knows that cp, -a, and /Users are different arguments because they have spaces between them. So how is the shell supposed to know that Dropbox (Personal) is part of the same argument, and not Dropbox and (Personal)? The answer is quoting: cp -a '/Users/aaronriddle/Dropbox (Personal)/Aaron Riddle Photography/Video/Virginia Elope Video Template' '/Users/aaronriddle/Desktop/'

Neither do they (well, they might), which makes this humorous from a Portuguese perspective. Portugal and Spain have similar languages and cultures—so honest mistakes are bound to happen—but tend to get annoyed when people confuse the two. We share a lot of history, so it’s our version of a sibling rivalry. Just be careful to not get it mixed up when speaking to someone in person or there’s a good chance they’ll resent you for real, even if they liked you up to that point. They’re thanking you for the help, and explaining their process in case someone else stumbles here with the same question.

Yes. You could do pip install something or brew install something, hardcode those installation paths in your Workflow, and get it done quickly. But then it’s a worse experience for other people, because you have to explain external steps they have to perform. If my Workflows have dependencies, I make sure they’re bundled or automatically / easily gettable from within the Workflow and that it doesn’t mess with people’s setup outside the Workflow.

The API issues have been solved (not everywhere), so I’ve removed the workaround from the Workflow. Also took the chance for the subtle icon update. You usage should be unaffected.

Update. Updated icon, and added support for DMGs. To update, download the latest version (same URL) or wait a few days and it’ll prompt you to on next usage, since it uses OneUpdater.

Getting a local dictionary to work is easy. The hard part is making it a good experience where the user doesn’t have to do any external setup.

@2Pants You’re not doing anything wrong. The API I use for the Workflow hasn’t been working (no discernible reason, everything else looks the same) and I haven’t yet found a replacement. Alternatives: Find another API.Use a local spell checker. Problems: Other spell checking APIs are paid or require registration.CLI spell checkers don’t provide compiled self-contained versions, and the ones in Homebrew are dependent on hard-coded locations. I haven’t yet explored the viability of compiling them myself, which even if successful would lead to another slew of problems because it would mean I’d have to host them myself (which I don’t want) or possibly make the Workflow’s license more restrictive, due to the GPL (which these spellcheckers all seem to be under). So it is possible to fix the Workflow, but I haven’t yet found a solution that doesn’t make some setup work for the user.

Update. New icon. Subtle; other Workflows will get the same treatment. Also changed to use the Random Utility (no change to your usage). To update, download the latest version (same URL) or wait a few days and it’ll prompt you to on next usage, since it uses OneUpdater.

The first one on this thread.

Don’t forget you can edit the top post to remove the blueutil requirement.

I assumed it would be just as simple, but since you are a Pythonista and I’m not, I was confident you’d reach the best solution from my examples.

There’s a dropdown on the bottom of the Updates tab in Alfred Preferences. Change it from updates to pre-releases.

@Acidham Just like OpenUpdater, it’s meant to be as simple as possible. Add the script to your Workflow. Doesn’t matter where you put it; it’s wherever is convenient to you.Inside any script that requires blueutil, run /path/to/_sharedresources blueutil.Set the result of the previous command to the PATH environment variable.Call blueutil as usual. In Bash you’d so something like (assuming _sharedresources and the script are in the same directory): PATH="$(./_sharedresources 'blueutil')" blueutil WHATEVER In Ruby: require 'open3' ENV['PATH'] = Open3.capture2('./_sharedresources', 'blueutil').first Open3.capture2('blueutil', WHATEVER)

Welcome @WritersCafe, Moving this to Workflow Help, because it would be better served like that. As far as I’m aware, there isn’t a user-facing way of saving session like it happens on shutdown / restart. That doesn’t simply save the open applications, but your state within them. Saving that to restore later might be too complicated (it would need to track changes that might be irreversible). But if all you want to do is to save a list of open apps and reopen them at a later date, that’s simpler to do (though it still requires coding).

Would you like it not to require users to have to manually install the dependency? I can help you set up _sharedresources, if you’d like. blueutil is supported, as I use it in one of my Workflows.

Thank you. Nope. It’s been a feature request on youtube-dl (which the Workflow uses) since 2015.

set browser_list to {"Safari", "Safari Technology Preview", "Google Chrome", "Opera"} set default_browser to "Safari" set web_address to "https://example.com" tell application "System Events" to set front_app to name of first process whose frontmost is true if browser_list contains front_app then tell application front_app to open location web_address else tell application default_browser activate open location web_address end tell end if

Had to remake it from scratch. Ugly but it works. Here you go.

As of now, this Workflow is officially deprecated (it will keep working, I just won’t update it in the extremely unlikely event it ever breaks), because Alfred natively provides the functionality starting with 4.1.

In this case I was thinking the agent wouldn’t do the updating, the Workflow would, called via an External Trigger (hence returning before the action is performed). If updating the agent itself would still be problematic, a way to go around it would be to make a new agent every time (append some random string), but that then leads to workarounds on how to delete the previous one. That can be problematic. If the machine is often off at 9:00, it may not fire often (more than what’s desired). If it’s asleep, the timer will also start later in the day. But even if it starts on time, the machine may be under heavy load or asleep several times during this interval, delaying the timer even further. Also, a crash may occur or a reboot might be necessary, which would kill the job. All of this contributes to the firing time being heavily skewed for the latter portion of the day, possibly even firing after 20:00 or not at all if the machine is turned off or asleep before then.