deanishe

If you create the "/Users/dustin/Library/Caches/com.runningwithcrayons.Alfred-2/Workflow Data" directory, that should fix the problem.

In a word, yes.
In a sentence, "no, but the other ways of doing it are either much more complicated or less reliable."
If you want to do it "properly", you might consider saving the previous contents of the clipboard and restoring them after you're done.
pbpaste and pbcopy are for you to get and set the clipboard contents on the command line (or in non-native scripting languages). They don't interact with applications in any way.

Yup, that's exactly it!
 
 
Don't get me wrong, I also feel icky running an Alfred search via AppleScript, but I feel that, on balance, it's preferable to External Triggers due to their funky UX. Adding the keyword to the env vars would be a simple way (in terms of effort for Andrew and the current execution model) to eliminate the fairly substantial risk of everything breaking because a user changed the keyword. It's a stopgap while we wait for that first-class way of telling Alfred what to display next.
 
I also like your idea of Alfred maintaining a stack. It's just that I think if Alfred is going to start tracking workflow state (which maintaining a stack would involve at some level, unless it's just doing some parsing of {query} for you), it may as well take it a bit further, so the workflow itself doesn't also have to worry about state (in the common case). As you say, stateful programming sucks, so clearly it's better to leave that to Andrew. That's what we pay him for
 
In terms of the execution model, your suggestion isn't a huge leap. It would make the UI a lot cleaner for users, but not change much for developers. What I'm suggesting would change the execution model significantly (although it shouldn't break existing workflows), but also provide significant benefits for developers.
 
In terms of effort for Andrew, neither is insignificant. I suspect the most significant component would be getting the UI for the breadcrumb navigation/stack right.
 
 
Both should work equally well in situations where the stack = the argument, such as directory trees. If you're working with API or database data, where every node has an ID, you'd want to pass the ID and wouldn't care about the stack (if Alfred were taking care of it for you).

In reply to Dean:
 
Your last explanation clicked for me
 
Let me try to explain what I see between our two approaches:
 
Tyler's:
UI sugar on top of the already-available workflow capabilities (delimiters, submenus) Developer is in the same position as previously Script filters act statefully, using tab-delimited inputs to rebuild state for each execution Pros:
Prettier UI Simpler to back out of an action (just remove the last entry from the stack) Cons:
Stateful programming sucks Developers receive no real help with control flow  
Dean's:
Send output directly to an (a.) action that does a thing (b.) script filter that return more options Each item is responsible for declaring where it should be sent if actioned No action or script filter needs to know how the last step got its result, it only needs the result Actions and Script Filters are labelled, basically eliminating the need for external triggers to pass data within a workflow Pros:
Stateless components Much simpler control flow Cons:
Could require significant rethinking of the Trigger/Input/Action/Output paradigm (may also be a Pro) To allow undo/back out, Alfred needs to maintain a stack of previous actions and the outputs sent to them  
I have an intuitive sense that each solution has a different optimal use case, but I haven't thought too hard about it. Maybe my idea would be better suited to simple drill-down navigation, while yours is better suited to control flow between functional components.
 
Either way, I like what I'm understanding about your solution. It's as big of a leap in capability as Alfred 2 was to Alfred 1.
 
To me, it sounds like script filters have outgrown their implementation. From what I'm seeing, a script filter does not always need to have a keyword, nor does it always make sense to do so.
 
It sounds like people want a first-class way of telling Alfred which UI to display next. The current solution (using Applescript to call an External Trigger or to populate Alfred with a keyword) is sub-optimal. I don't know about you, but I feel dirty every time I type osascript -e 'tell application "Alfred 2" to search "keyword"'.
 
I can see benefit to having the keyword in the environment if you want a quick fix that's as dirty as Applescript, but not if the system itself were built to handle this interaction better. If workflow objects had developer-specified labels, the keyword chosen by the user would be irrelevant.

What about a new value for the type attribute? Something like type="category". When actioned, the icon of the category is placed into Alfred's UI similarly to the way External Triggers do.
 
Example of how it would work:
 
User is activating a workflow that uses a script filter to drill into a folder structure to find a specific file
 
User activates script filter with "drill alpha-folder"
User selects item with:
type: "category"
arg: "/alpha-folder"
icon: "alpha-icon.png"
 
Alfred places "drill-icon.png" and "alpha-icon.png" into the left part of the UI (as occurs for External Triggers)
Alfred sends "/alpha-folder" as query to script filter
​Script filter responds with results from /alpha-folder
 
User selects item with:
type: "category"
arg: "/bravo-folder"
icon: "bravo-icon.png"
 
Alfred places "bravo-icon.png" above/next to "alpha-icon.png" to indicate hierarchy (at some reasonable point, icons collapse instead of stacking at full width)
Alfred sends "/alpha-folder [tab] /bravo-folder" as query to script filter (tab separated, similar File Actions)
Script filter responds with results from /foo-folder/bar-folder
 
User presses delete key
 
Alfred removes "bravo-icon.png" from UI stack
Alfred sends "/alpha-folder" as query to script filter
​Script filter response with items from /alpha-folder
 
User selects item with:
type: "file"
arg: "/alpha-folder/charlie-name.txt"
icon: "charlie-icon.png"
 
Alfred sends "/alpha-folder/charlie-name.txt" to the next action
Action does whatever it does, just like always…
 
Let me know what's good, bad, and/or ugly about this solution. I'm very interested to hear how other people would approach this issue, especially those with more experience developing hierarchical workflows.

Not easily.  I looked into this a few months ago and it looked like it would be a lot of work to figure out the Amazon Cloud Drive API -- there are no ready made command line tools, Applescript interface, or anything more user-friendly like that.   I already have an automated off-site backup solution (Backblaze) so I decided not to pursue it.
 
Having said that, I don't think Alfred is the right tool for the job in any case.  Alfred is great for user-initiated actions - searching, launching tasks / apps / opening files etc. - but it's not made for doing stuff in the background based on other kinds of triggers (e.g. run a script when a camera is connected, etc.).  For that I'd use Hazel.

FlixSearch for Alfred

See what's available on Netflix and where via FlixSearch.io.




Download & Installation

Download from GitHub releases or Packal. Double-click the FlixSearch-x.x.alfredworkflow file to install.

Usage

Note: You must activate one or more countries before the workflow will work.
flix <query> — Search FlixSearch.io for <query>. ↩ — Open the FlixSearch.io page in your default browser. ⌘ — Show video's genres in the subtitle. ⌥ — Show countries in which video is available in subtitle. ^ — Show FlixSearch.io URL in subtitle. ⇧ — Preview FlixSearch.io webpage with Quicklook. flixconf — Show workflow update status and configuration optionsUpdate status. Show whether a newer version of the workflow is available for download. Configure countries — Activate/deactivate countries to include in/exclude from search results. Activate the countries you visit or have VPN endpoints in. View help — Open this help file in your default browser. Reset workflow — Clear workflow cache and settings.  
 
Licensing, thanks, etc.
 
Please see the GitHub repo for details.
 

I've written a command-line script that will automatically change your Alfred theme at sunrise and sunset. It's kind of a companion to F.lux and its option to turn on Yosemite's dark theme when it gets dark.
 
It requires the pytz and astral Python libraries.
 
Save the script somewhere and run it in Terminal:
 
python toggle_alfred_theme.py --dark 'My dark theme' --light 'My light theme'  
The script will change the current theme depending on the time of day and then schedule itself to be called every sunrise and sunset (or when the computer boots/wakes) to change Alfred's theme.

With regard to files, Alfred's standard mode of operation is to first find the file (or files), and then select the action.
 
This has the distinct advantage of working with all File Filters and workflows, making it much faster to find the file you're after.
 
To these ends, it's trivial to create a workflow with a "Delete" or "Trash" File Action.
 
You can then hit right arrow (the default key) on any Alfred result of type "file", to perform your Delete/Trash action.

Well first off, the workflow doesn't do anything stupid like store your passwords.
 
Fundamentally, to use any encrypted data, it first needs to be decrypted.
 
With any password manager, when your encrypted store is unlocked, either the master password/decryption key or the decrypted passwords are now in memory.
 
I don't know exactly how the LastPass CLI program works, or how it differs from the browser-based applications, but your data is fundamentally at risk whenever the password store is accessible (i.e. unlocked). Personally, I'd be more inclined to trust software that isn't directly connected to the browser I'm entering the password in: it insulates your sensitive data better from bugs in the browser or extension.
 
To maximise security, you want the password store to be automatically locked after use. The shorter the time it remains unlocked, the better.
 
In that regard, disabling the agent timeout is not a great idea, but it's no worse than setting the browser extension to never time out.
 
Ultimately, it's always a compromise between security and convenience. If you're happy to enter your master password every time you need a site password, then that will minimise the possibility of your passwords being pilfered from your machine by malware. On the other hand, if you leave your password store unlocked whenever the app is running, that makes it more tolerable to use a longer, stronger master password, which makes the encrypted data stored in the cloud more secure.

VPN Connection Manager

Manage your Tunnelblick or Viscosity VPN connections from Alfred.


 
 
Usage
vpn [<query>] — View and filter Tunnelblick/Viscosity VPN connections.
    - ↩ — Connect/disconnect selected connection. vpnconf [<query>] — View and edit workflow configuration. Workflow Update Available! / Workflow Is up to Date — Workflow update availablity. ↩ or ⇥ — Check for and install update. App Name (active) — The currently selected VPN application.  App Name (not installed) — Supported, but not installed, VPN application.  ↩ — Go to this application's website.  App Name — Installed, but unused, application.  ↩ — Use this application to manage VPN connections.  Online Docs — Workflow README. ↩ — Open in your default browser.  Help — This forum thread. ↩ — Open in your default browser. Report Problem — Workflow's GitHub issues. ↩ — Open in your default browser.  
If you haven't entered a query, any active VPN connections will be shown at the top of the list. Action an active connection to disconnect it.
 
If you are connected to multiple VPNs, an additional "Disconnect All" item will be shown first.
 
Download & Installation
 
Get the workflow from GitHub releases.
 

VPN Connection Manager

Manage your Tunnelblick or Viscosity VPN connections from Alfred.


 
 
Usage
vpn [<query>] — View and filter Tunnelblick/Viscosity VPN connections.
    - ↩ — Connect/disconnect selected connection. vpnconf [<query>] — View and edit workflow configuration. Workflow Update Available! / Workflow Is up to Date — Workflow update availablity. ↩ or ⇥ — Check for and install update. App Name (active) — The currently selected VPN application.  App Name (not installed) — Supported, but not installed, VPN application.  ↩ — Go to this application's website.  App Name — Installed, but unused, application.  ↩ — Use this application to manage VPN connections.  Online Docs — Workflow README. ↩ — Open in your default browser.  Help — This forum thread. ↩ — Open in your default browser. Report Problem — Workflow's GitHub issues. ↩ — Open in your default browser.  
If you haven't entered a query, any active VPN connections will be shown at the top of the list. Action an active connection to disconnect it.
 
If you are connected to multiple VPNs, an additional "Disconnect All" item will be shown first.
 
Download & Installation
 
Get the workflow from GitHub releases.
 

This probably won't help: it's a problem specific to Python's (dumbass) encoding/decoding behaviour
 

  Alfred uses exclusively UTF-8 input and output. 
 
String encoding in Python 2 is a bit of a bitch, unfortunately.
 
From a brief perusal of the source code on GitHub, your script actually does not convert any input from UTF-8 to Unicode.
 
This isn't necessarily a problem with Python 2, as it can work just fine with encoded strings, but you're using the json module, which returns Unicode, and trying to encode (potentially bytestrings) with ElementTree. If you try to call a Unicode function with a bytestring, Python 2 will typically try to decode it with the ASCII codec first, which is why your workflow works just fine with ASCII input, but blows up when given non-ASCII input.
 
I haven't installed or run the code, but I think changing line 144 to query = sys.argv[2].decode('utf-8') will fix the problem.
 
The Golden Rule with text encoding/decoding in Python is to do it at IO boundaries (i.e. decode all incoming text, encode all outgoing text).
 
Seeing as you're writing a workflow in Python, might I suggest you have a look at the Alfred-Workflow library, which will take care of most of the encoding/decoding for you (and a lot of the other mindless crap, too)?

Addendum: Here's an intro to string encoding I wrote, with a focus on Alfred workflows (but more particularly Alfred-Workflow).

A new workflow that has quickly become a firm favourite: Search OmniFocus.
 
Because it directly accesses OmniFocus's sqlite database files instead of using AppleScript to talk to the application, it's insanely fast. This makes is so much more useful than other OF workflows.
 
Insanely fast.

Use a Run Script Action with language = AppleScript:

tell application "System Events" to keystroke "/" using {command down, option down, control down}

There is no API, unfortunately. The workflow parses the website HTML.
 
I've updated it to handle the changed HTML.
 
Download from GitHub or enter duden workflow:update into Alfred to grab the new version.

Marvellous. That's very handy.
 
A useful stop-gap in my one man crusade to get app developers to stop defining their own UTIs for common formats.

Hey FirePanther, I removed your own workflows from your post because, as I wrote in the OP (and quoted in your post), this isn't the thread to pimp your own wares.
As Vítor astutely noted above, everyone thinks their own workflows are must-haves: that's usually why they wrote them in the first place…

To confirm your suspicions, OS X only indexes AFP-mounted remote volumes.
 
As a result, Alfred (and Spotlight) will only show results from remote volumes that are mounted via AFP. Volumes mounted via SMB, SSHFS etc. won't be indexed.
 
If you absolutely have to search a non-AFP remote volume, you'll probably have to create a workflow based on locate or a similar tool.

Yeah, that's not such a great idea. You'd be better off opening the workflow in Terminal and using pip install --target . flask to install the library in the workflow.
 
Flask probably won't cause much trouble, as its API is pretty stable, but it's generally not a great idea to install any libraries in the system Python. If you must, use pip install --user <libname> (without "sudo"). That will install them under your own home directory, where they won't go missing during a system upgrade.

Displays a monthly calendar. 
 
Download
 
Usage
cal [month [year]] [<] [>]
enter ↵ Open Supported Calendar Software with week view on selected week. <, > Display calendar of previous/next month. [month [year]] Display calendar with specific month and year. month can be numbers or English words. calconfig More configuration options.
Supported Calendar Software BusyCal Fantastical 2 Google Calendar OS X Calendar    
Screenshots
 



 
ChangeLog:
 
Version 1.3.1
1. Support Google Calendar
 
Version 1.3;
1. Support BusyCal and Fantastical 2. 2. Optimize write operation to config file.

I'm going to invoke the power of Cunningham's Law a wee bit to get someone who knows Ruby well to answer your question, too…
 
Absolutely Python. No question. It's much more readable than Ruby and has a much better community.
 
When it comes to Alfred workflows in particular, my Alfred-Workflow library for Python is streets ahead of the Ruby competition in terms of how much of the grunt work it can take off your hands.
 
There are awesome tutorials available for Python:
Dive Into Python How to Think Like a Computer Scientist Learn Python the Hard Way (it's not actually hard) A Byte of Python And my own tutorial for writing workflows in Python with Alfred-Workflow.

Nah, this thread helped me fix my own iTerm AppleScripts 

Are you good with Perl?
If not, you might want to consider using another language like Ruby or Python. They're a lot easier to use, and you'll get more help on here because they're much more popular with workflow authors.