deanishe

Is it really incorrect to want a subtler colour for the cog?

It might be handy to have the bundleid and possibly the name of the workflow. I mostly use the bundleid for calculating the data/cache paths (which will hopefully be added), but also for naming, e.g., log files. It'd be great not to have to parse info.plist.

Oh right, I see what you mean.

Thanks. The problem for me is I try to make the "cog" very subtle in my themes, so that setting isn't useful for determining whether a workflow should use its light or dark icons (which is what I was hoping to use if for). No matter. The theme background works a treat for that, as Shawn had already done the hard work of figuring out an algorithm to determine a colour's darkness The cache and data paths would be useful. If a workflow script relies on those, however, you can't test it from a shell. Or am I the only one who does that?

You say, "bug", I say "misunderstood feature".

Right. I thought it indicated whether you should use "light" or "dark" icons on that background. Pity

This is totally awesome. Does alfred_theme_iconstyle mean what I think it means, or is this a bug? The values seem to contradict those in your example, Andrew.

I only meant that my proxy.pac was definitely sending PROXY XXX, not DIRECT, when it sees Alfred's user-agent, i.e. I wasn't sending the wrong value. I hadn't thought that through properly. I looked at the proxy.pac format again, and it just doesn't work that way. The client is supposed to call the FindProxyForURL(url, host) defined in proxy.pac for every URL (hence the point-in-time resolution), which Alfred can't do for its workflows. Static values for http_proxy and https_proxy are the shell standard for proxy servers, and Alfred can't be expected to provide more that than. Any script that works with a proxy server from a shell should now also work in Alfred, but with the sweet bonus that Alfred also automatically adjusts the proxy server based on OS X's Network Location, which you can't do properly in a shell. Thanks very much for adding this feature to Alfred. It isn't really possible to do from within a workflow, and that made a lot of them useless for some users pre 2.4. I guess Auto Proxy Configuration will have to remain the exclusive preserve of Objective-C workflows…

Until smarg19 breaks it, which he always does, the blighter.

You don't need to check everything. Only the options specified here. No point escaping spaces in a string enclosed in quotes. That said, it seems to work just fine. Great work!

Fundamentally, Terminal.app (and iTerm.app) do not export any proxy settings in System Preferences to shells. iTerm.app itself does use the system proxy when checking for updates because it's a Cocoa app, but neither of the apps do (or can be configured to) export the proxy settings to the shells running within them. Shells apparently run at the lower UNIX system level, while the proxy servers configured in System Preferences belong to the Objective-C runtime. To use a proxy from anything that's standard UNIX in the shell, you have to set http_proxy/https_proxy manually. Any settings in System Preferences are ignored. Auto Proxy Discovery and Automatic Proxy Configuration are two different, but related, things. The former is a protocol usually used to find the latter, which is a JavaScript file that when executed tells the client whether to use proxy server XXX or connect directly. I have my proxy.pac set up to tell applications to either use the proxy server or connect directly based on the user agent. I want some apps to use my ad-blocking proxy and others to be subject to Little Snitch. Alfred is always given the proxy. I've run a few tests, changing my proxy.pac file to always specify the proxy server, and never direct, but still using Automatic Proxy Configuration. In that case, Alfred uses the proxy (to check for updates etc.), as does targumanu's IMDb workflow, which is written in Objective-C, however the http_proxy and https_proxy environmental variables remain empty in Alfred's calling environment, so Python/Ruby/cURL do not use the proxy server. To be clear, it's unreasonable to expect that my proxy.pac would fully work with workflows (i.e. they run proxy.pac and it sends DIRECT or PROXY XXX back based on the workflow's user agent), but Alfred is being told to use the proxy and isn't propagating that setting.

Got you. Working fine now. Great work. You should probably think about using Alfred's Escape options: if someone enters a query with ", $, ` or \ in it, the workflow won't work properly.

Terminal.app/iTerm.app don't set http(s)_proxy for you, regardless of the settings in System Preferences > Network. Proxy env vars have to be set manually or in your dotfiles.

It doesn't really compare to the OED, does it? That thing's huuuge… Can't you just use AppleScript to "press" CMD+C, then bring OED to the front? activate should even work for apps written in Flash.

Any sign of Python 3?

It wouldn't work at all for me. I tried deleting the --escaped argument, and now it does. Is there a reason you're not using Alfred's Escaping options? Normally for bash, you'd want Backquotes, Double Quotes, Backslashes and Dollars.

Sweet. It works fine if I set the proxy manually via "Web Proxy (HTTP)" and "Secure Web Proxy (HTTPS)": all my Python workflows automatically use the proxy. Unfortunately, it doesn't work with Automatic Proxy Configuration, which is what I use Alfred itself has no trouble picking up and using the proxy. I've just watched it hit media.alfredapp.com/v2update/ via the proxy log. I'm not sure how common it is to use a proxy.pac configuration file, but it's how I always used to do it when I was in charge of a network.

Not sure, to be honest (I don't have SL to test it on). It should be, however. I don't believe it uses any Python features that weren't around in 2.6. Give it a try, and if there are any errors, we might be able to fix them.

I've uploaded a new version with a different URL for Google and an optional setting to toggle showing the query in the search results (use searchio to view the setting and action the "Show query in results" item to toggle the setting). Could you give that one a try and see if Google now works properly for you?

It was probably a connectivity error, by the looks of it. The main bundler archive wasn't downloaded correctly, and the bundler wrapper isn't yet smart enough to recover from that (one of the reasons it's still really not production ready). Unfortunately, there also isn't an easy way to uninstall the bundler, so it can try again. Ask your user to delete their ~/Library/Application Support/Alfred 2/Workflow Data/alfred.bundler-aries directory and try running the workflow again (with an Internet connection). You might want to consider adding a command to your workflow that can delete the bundler until it's stable.

What browser are you using? When you action a search result in the workflow, what URL does your browser show?

They have changed their stance: you now have to enter your user password to view a password (which makes it as safe/unsafe as Safari and Keychain). Your PIN would be protecting nothing but a URL. The URL is probably available in your Chrome history, anyway (if you didn't use porn mode), and definitely in your list of saved passwords. If you want to do this anyway, you have 2 options as I see it: Store the URL in Keychain using the security utility. At least this way, it isn't in plain text on your HD. Encrypt the URL, require a password to be entered as a query to your workflow, and decrypt the URL before opening it in your browser. In either case, you're not adding much in the way of security. If you want actual security that isn't easy to get around, do what Vitor says and use a proper password manager like 1Password to store the username and password.

I found myself using Duden a lot, so I wrote a Duden workflow with live search suggestions here.

Alfred Duden.de Search Workflow Search the definitive German dictionary at Duden.de with auto-suggest. Download and installation Download the Workflow from the GitHub releases page or Packal. Double-click the Duden-Search.alfredworkflow file to install. Usage Default keyword is duden. Enter your query after that. Actioning a result with RETURN will open the full results page at duden.de in your browser. Holding ⌘ on a result will show the URL it will open. Licensing, thanks The code of this workflow is released under the MIT licence. This workflow is based on the Alfred-Workflow library (also MIT-licensed).

Hmm. No, it shouldn't be doing that with Google. I did try with including the search query as-is as the top result, but ultimately decided against it. If that's what folks want, I'll put it back in. If you don't mind hacking the source a wee bit, if you comment out line 112 in search.py and uncomment lines 114 and 115, that will make the entered query the first result. Using a modifier to turn off suggestions won't work, as that isn't how Alfred uses modifiers. In that case, I'd suggest assigning, for example, the keyword s to a standard Alfred Web Search and si to a Searchio! auto-suggestion search. It should be easy enough to add other search engines, depending on their suggestions API.