Neberheim

I played around with Cardhop and here is a workflow that I made. I wanted to get more time before sending some workflows to the forum to setup a repository and with an auto-update to the workflow, but I didn't have the time yet for that. And since some people mentioned that they would like a workflow for Cardhop, here is one!
 
Features:
Keyword "chc" : Search a contact in Alfred and open it in Cardhop Keyword "chs" or hotkey : Send the query to Cardhop. If the query is empty, it tries to get the selection from the front application and send it to Carhop (In short, you can select the contact information on it's website or email and call "chs" from Alfred and the selection should be sent directly to Cardhop). You can use this action to send the selection or pass a string to your Favorites list (alternative to keyword: chf) or to the Cardhop's Actions (alternative to keyword: cha). Keyword "chf" : Send a string from your Favorites list directly to Cardhop (could be used as a Snippets/Bookmarks list to rapidly write a query to Cardhop that you know gives you the right information in it without the need to write it all). Write your list in the Workflow Environment Variables "Favorites" and separated by semicolon (";"). Ex: Call mom home;Mail boss work;facetime Complicated Name;website businessName;/MyTag;Direction dentist... A variable "{q}" could be used to have a placeholder for a string that you want to set just before sending to Cardhop (ex: "Email {q} work" where {q} could be changed to any name at the time that you invoke the workflow). Tip: To directly activate an action in Cardhop, it seems to delay the input until it has done parsing the query, so you can rapidly press Enter a second time when you select an item from your Favorites list in Alfred and it should run the first action that Cardhop returns. Keyword "cha" : Show a list of possible Carhop actions. If arriving to this function using the Send feature (chs), then the selection or query would be appended to the Cardhop action before sending it. Hotkey to Send selection to Cardhop : If you prefer to send the selection directly to Cardhop with a hotkey instead of a keyword Fallback search to send the query to Cardhop : If you want to write the information directly in Alfred without any keyword before. To make it works, you would need to add the Fallback search into the Alfred Preferences at: "Features/Default Results/Setup fallback results/+/Workflow Trigger/Send to Cardhop" External trigger to send a string to Cardhop from an external script. Other external triggers are set if you want to pop the Favorites list or Actions list from an external script. Append/Prepend string : Add a string before or after the main string before sending using a predefined list or any string if the query doesn't match an item in the list (Could be useful to have a list of predefined group/tags) (See "Workflow Environment Variables" and "Navigation" lists below)
Workflow Environment Variables:
Favorites List: See keyword "chf" above AppendToSend : Set a predefined list of string to append using the Append feature (ALT key) PrependToSend : Set a predefined list of string to prepend using the Prepend feature (CTRL key)
Navigation:
CMD key : Go to the Send feature Actions List (chs) ALT key : Activate the selected item and append extra string (using the AppendToSend list) CTRL key : Activate the selected item and prepend extra string (using the PrependToSend list)  
Tip: If you want to use Cardhop as the application to open from Alfred when you are viewing a contact with the Alfred Contact Viewer and press CMD+O: Insert "x-cardhop://show?id={uid}" into the Alfred Preferences at "Features/Contacts/Advanced/URL Handler" instead of using "addressbook://{uid}". This should do the same as the keyword "chc" but without the need to write the keyword before searching for a contact and use directly the built-in contact search of Alfred
 
Download Link (latest version): https://d.pr/f/SX4Sn7
 
Download Link (older version, latest version using Python 2): https://d.pr/f/rQTPtu
 
Have fun!

Dude, how are you so awesome? Trying to get Zotero to work better for me is what led me down the rabbit hole to finding Alfred in the first place. I’m ecstatic that there’s some active development on this front, and out of altruistic intentions at that. Python is installed and I’m learning a bit at a time. I hope I can help contribute to this in the future; I’ll certainly be using this workflow until then.

Write as you’d do in markdown, inline code between single backticks, select the text and press the keyboard shortcut you assigned to the action.
 

I guess that means we’re both bad at reading to the end hahaha

Dude, how are you so awesome? Trying to get Zotero to work better for me is what led me down the rabbit hole to finding Alfred in the first place. I’m ecstatic that there’s some active development on this front, and out of altruistic intentions at that. Python is installed and I’m learning a bit at a time. I hope I can help contribute to this in the future; I’ll certainly be using this workflow until then.

Hurrah for webdevs and their inability to learn anything more complicated that JavaScript!

I searched this forum and didn't find any thread on this but I wanted to propose it for a long time now.
 
I very often use Discourse based forums like KM forum or Swift forum. And the experience in there is in many ways so much better than here. The interface is much cleaner, there is native markdown support, the search is better and more intuitive. I can't find anything this forum does better than Discourse can.
 
I also have been reading this forum for a long time and lack of markdown in writing things is a very obvious paint point. There was a thread made 2 hours ago that mentions this very problem. I myself am quite annoyed too by the fact that I am forced to use an external tool like MarkdownTransform just so I can in some comfort markup my text in this forum and run it through the tool later.
 
Also Discourse supports night theme which is a small cosmetic change but with Mojawe coming soon would be quite appreciated. 
 
It seems the big reason why this change can't be made is that you can't translate the content that is written on this forum to Discourse. Which if true, while sad, makes complete sense why we still use this forum software. But if that is not the case and there is a way to import all content into a new Discourse instance. I think this change would be really nice for the users.

Not sure it’s possible without using an external tool (which I’m avoiding for this particular Workflow). Either way, Workflows for toggling Bluetooth are short to make and there are too many ways to go about it, so for this one I want to solve a very particular issue: people who rarely turn on bluetooth and then forget to turn it off, which is why it works like it does.
 
 
I recommend instead you take a look at Bartender (paid) or Vanilla (free).
 
 
Obligatory XKCD.

Same.

I’ve made a tiny update. So tiny, I haven’t even given it a version bump. I’ve updated the icon, but in a way that the corrections are so small, you’re unlikely to notice them (even if you look at them now). But they matter to me, and my consistency with the Alfred icons I design. Just posting in case you’re obsessive about getting the exact right Workflow (download is at the same link).

Usage

Search your paired bluetooth devices via the btd keyword. Press ↩ to reverse a device’s state (on becomes off, and vice-versa).



Toggle bluetooth as a whole via the btt keyword.



⤓ Install on the Alfred Gallery | Source
 

The Alfred docs are limited to the workflow-y bits. The rest of building a workflow is UNIX command-line programming. Realistically, that's way beyond the scope of Alfred's docs, as it's a very broad topic. There are fundamentals that apply across languages, like environment variables, STDIN, STDOUT & STDERR and ARGV (command-line arguments), but really you should be off learning how to write Python or Ruby (or Swift).
 
Swift is a fine language—with several advantages on the Mac over non-Apple languages—and runs fast. You could use just about any language, however, and I'm not sure I'd recommend Swift as a first language (unless you want to write Mac/iOS apps): the language itself is a good one, but Apple's (Mac) libraries that it uses are complicated and badly documented. Indeed, the docs are similar in nature to Alfred's: they're great if you already know what's going on and not much help at all if you don't…
 
You get much more done more quickly with a language like Ruby or Python, and they're more flexible, too. Python in particular is a great first language with lots of docs aimed at beginners. Unfortunately, Apple ships a really old version of Python 2, not the current Python 3, and there are some important differences between the two. I'm not sure I'd recommend learning Python 2 at this point (it's dead).
 
As regards a workflow to manage your NordVPN connections, is this OpenVPN workflow no good?
 
If you want their IKEv2 VPN, you'll need to use Apple's APIs to manipulate your network settings. That can be done with AppleScript or Swift. AppleScript is probably a lot easier, if it's capable of what you need. Swift uses much lower-level APIs and will be much harder to use.
 
Here's an AppleScript to connect to a VPN via Network Preferences.

Introduction
 
Alfred workflows are simply zipped directories with an altered extension. Those are great news if you want to automate packaging your workflows for distribution, as you can simply (using ditto in this example, but zip would work just as well):
 
ditto -ck "{{/path/to/your/workflow_directory}}" "{{/path/to/your/output_file}}.alfredworkflow"
And that’s it. A zipped directory of your workflow with the custom .alfredworkflow extension. Names enclosed in double curly brackets are examples (they dependend on your situation and must be edited accordingly).
 
Problem

The trouble with that solution is that it packages your workflow as is. Most of the time that won’t be a problem, but it becomes one when you have Workflow Environment Variables with “Don't Export” activated or have made local changed to your configuration. Alfred knows not to save the value of those variables or your custom configuration when exporting your workflow, but your zipping utility does not. Because of that, if you want to package your workflow yourself you need to set those variables (and only those) to empty values and exclude the prefs.plist file.
 
Solution
 
# You need only set these two variables, and the rest will work as is readonly workflow_dir="{{/path/to/your/workflow_directory}}" readonly output_file="{{/path/to/your/output_file}}.alfredworkflow" # Leave this section as is if /usr/libexec/PlistBuddy -c 'Print variablesdontexport' "${workflow_dir}/info.plist" &> /dev/null; then   readonly workflow_dir_to_package="$(mktemp -d)"   cp -R "${workflow_dir}/"* "${workflow_dir_to_package}"   readonly tmp_info_plist="${workflow_dir_to_package}/info.plist"   /usr/libexec/PlistBuddy -c 'print variablesdontexport' "${tmp_info_plist}" | grep '    ' | sed -E 's/ {4}//' | xargs -I {} /usr/libexec/PlistBuddy -c "set variables:'{}' ''" "${tmp_info_plist}" else   readonly workflow_dir_to_package="${workflow_dir}" fi DITTONORSRC=1 /usr/bin/ditto -ck "${workflow_dir_to_package}" "${workflow_file}" /usr/bin/zip "${workflow_file}" --delete 'prefs.plist' > /dev/null
So, what does this do?
Check the info.plist in your workflow directory for the variablesdontexport property. If the property does not exist, jump to step 5. If the property exists, copy your entire workflow to a temporary directory (we’ll make changes to the info.plist and don’t want to do them on our current one). Check every variable in variablesdontexport and set them to empty values in the info.plist of the copied directory (we don’t want to outright delete the variables as the reference would be lost as well). Package the directory to a workflow. Delete the `prefs.plist`, if it exists, from the packaged workflow. Our work is done.  
Solution as a script
 
#!/bin/zsh readonly workflow_dir="${1}" readonly info_plist="${workflow_dir}/info.plist" if [[ "$#" -ne 1 ]] || [[ ! -f "${info_plist}" ]]; then   echo 'You need to give this script a single argument: the path to a valid workflow directory.' echo 'The workflow will be saved to the Desktop.'   exit 1 fi readonly workflow_name="$(/usr/libexec/PlistBuddy -c 'print name' "${info_plist}")" readonly workflow_file="${HOME}/Desktop/${workflow_name}.alfredworkflow" if /usr/libexec/PlistBuddy -c 'print variablesdontexport' "${info_plist}" &> /dev/null; then   readonly workflow_dir_to_package="$(mktemp -d)"   /bin/cp -R "${workflow_dir}/"* "${workflow_dir_to_package}" readonly tmp_info_plist="${workflow_dir_to_package}/info.plist"   /usr/libexec/PlistBuddy -c 'Print variablesdontexport' "${tmp_info_plist}" | grep '    ' | sed -E 's/ {4}//' | xargs -I {} /usr/libexec/PlistBuddy -c "Set variables:'{}' ''" "${tmp_info_plist}" else   readonly workflow_dir_to_package="${workflow_dir}" fi DITTONORSRC=1 /usr/bin/ditto -ck "${workflow_dir_to_package}" "${workflow_file}" /usr/bin/zip "${workflow_file}" --delete 'prefs.plist' > /dev/null echo "Exported worflow to ${workflow_file}."
To use that script, give it a single argument: the path to the workflow you want to package. It’ll save it to the Desktop with the name automatically determined.