deanishe

I love the meaningful indentation. It forces people to indent their code properly. I have to maintain a pretty big PHP webapp at the moment, and the indentation appears to be entirely random. It drives me nuts trying to follow the control flow The best thing about Python, imo, is exactly that it almost forces you to write readable code. It's actually harder to obfuscate it. Give this a try in Python: from __future__ import braces

What you would probably want to do is create a File Action that saves the path(s) to the selected file(s) and then calls Alfred to run a Script Filter that lets you choose you Adium contact. Finally, the contact is passed to a Run Script action that retrieves the saved filepath(s) and uses Adium to send the files to the contact. I have no idea if Adium provides the necessary APIs to get a list of its contacts and send files to them.

Marvellous news! I've spent far too many hours trying to get this to work in my workflow library without success. It can only reasonably be done from the Objective-C runtime Best of all, that means that Ruby/Python/cURL will Just Work™ without workflow authors having to even think about proxies. Would there be any possibility of setting the LANG variable (and perhaps the LC_* vars where appropriate) as well? It's not particularly difficult to the language from defaults, but it's not entirely straightforward, either. I've no idea when Apple will update the system Python to Python 3, but FWIW Python 3 workflows will not work (without a lot of arcane hackery) within the C (ASCII) locale Alfred currently calls workflows with. This is a bug with Py3, IMO, but the core developers consider it a feature

I've never understood the aversion to the indenting thing. I mean, don't you indent code in other languages properly, too? Or am I just excessively anal about indentation in all my code because I mostly write in Python?

I'm not sure it's worth it, tbh. To make it useable, we'd have to integrate it into the bundler/wrapper such that the proxy is automatically and transparently set. Otherwise, it's just additional boilerplate ("btw, if you want your workflow to work with proxy servers—which you should—you have to add this extra code every single time.") And even then, all the other workflows that don't use the bundler still wouldn't work with a proxy, which would be a confusing situation for most users, and possibly kick off a load of bug reports ("workflows A, B and C work with my proxy, so why doesn't yours?"). I suppose you can leverage that into "build your workflows with bundler, then it will work everywhere!", but I really do think this is something that belongs in Alfred itself. It's an environmental settings (like locale), and the environment is Alfred's responsibility. It runs workflows in a UNIX environment, so it should provide a sensibly-configured one (with http_proxy, LANG and the LC_ family of variables set to match the Cocoa environment), instead of passing on launchd's almost empty environment. Trying to recreate the user's environment in a UNIX-y way in the almost empty one Alfred provides is tricky (LANG) to practically impossible (http_proxy) from within a workflow when you don't have access to the Objective-C runtime.

A discussion of this topic. TL;DR: workflows do not—and never will—work with proxy servers without support from Alfred. This would be relatively trivial for Alfred to implement, but extremely difficult—maybe impossible—for a workflow to do (unless it's written in Objective-C). And it would need to be done in every single workflow.

Yeah, Andrew, with any luck… Thinking about it a bit more, it's kinda nonsensical to add such a utility to the bundler: how would it be installed if the wrapper can't access the web because it doesn't know about the proxy server… Are we supposed to base64 encode the binary in all the wrappers, and then install and call it from there? That's not only ridiculous, but also the only solution that would consistently work. I know folks who can only access the web via a proxy are a small minority (and usually then only part of the time), but given how simple this would be for Alfred to do and how ridiculously difficult it is to do from a workflow, and that it would need to be done in every single workflow, I really think that this is something Andrew should be doing. If Alfred set the http_proxy and https_proxy environmental variables before calling a workflow (which is relatively trivial for it to do vs the hoops a workflow author not using Objective-C has to jump through), it's something the majority of workflow authors will literally never even have to think about: it will be transparently taken care of it for them by the library/program (not 100% sure that PHP does so, but Ruby, Python, cURL etc. automatically use proxies set in this fashion). There's literally no way on earth that every workflow author is going to consider—let alone implement—proxy support. I mean, as a workflow author, what do you say when a user says—as in this thread—"I'm behind a proxy server. How do I get your workflow to work?" Do you tell them, "sorry, it would take as much effort as I expended on the workflow to get proxy support working, and it still likely wouldn't work" (assuming that's within your capabilities), and/or, "sorry, the workflow would run 5x slower if I implemented proxy support"? Or do you tell them, "sorry, Alfred doesn't support proxy servers with workflows. Try talking to Andrew, who's shown zero interest in the matter so far, or look for an alternative to Alfred"? To my mind, proxy support (or the lack thereof) is 100% a matter for Andrew. As a library or (especially) platform provider, it's kinda your duty to take care of this kind of arcane crap, so your users don't have to (if you want your library/platform to be seen positively). (I spent a lot of time trying to build Alfred-Workflow in such a way that users wouldn't have to overly worry about Unicode—a massive source of problems in Python 2 for those that aren't familiar with it.) Certainly, I don't see the point in my spending several hours trying to get my workflows to support proxy servers (and seriously hurting their performance) when no other workflows do. Sure, it's kudos for me, but are such users really going to stick with Alfred? The way I see it, either Andrew has Alfred export the necessary environmental variables, or he should post a clear "Powerpack largely useless with proxy servers" warning. As noted above, the only reasonable way around Alfred not supplying workflows with the necessary environmental variables is to include a Mac-native helper app in every single workflow. IMO, this is a crystal-clear case of "this is something Alfred needs to do itself".

Python/Ruby/cURL etc. all transparently support proxy servers, but it has to be set in a UNIX-y manner (via http_proxy environmental variable). The problem is, neither OS X nor Alfred do this. I think you'll find the workflow isn't actually using the proxy. Your machine just also allows web access without using the proxy (unless it's a transparent proxy). Workflows do not use a proxy because neither OS X nor Alfred propagates proxy settings to the standard http_proxy environmental variable or otherwise provide that information in a usable manner. If your machine can only connect to the web via a proxy server, workflows will not work unless the author has taken steps to ensure it does work. Which is exceptionally hard, bordering on impossible. It's certainly way beyond the scope of your average workflow. That's a massive, massive can of worms (I've looked into it because I use a proxy server). The only reasonable way for workflows to use proxy servers is for Alfred to pass the proxy settings to the workflow via the environment. It's super trivial for a Cocoa app to get the proxy server, but almost impossible for a workflow script to do so. Here's why: I've apparently got 11 enabled services (NICs, iOS devices, other phones, FireWire, bluetooth, VPN etc.). Being selective about it, I'd only need to check "Wi-Fi", "Ethernet 1" and "Ethernet 2" (though, of course, I could have a proxy set for my VPN etc.) , and I also need to run up to 3 commands per connection (Ethernet 2 is my LAN connection): $ networksetup -getwebproxy 'Ethernet 2' Enabled: No Server: 192.168.0.1 Port: 3128 Authenticated Proxy Enabled: 0 $ networksetup -getproxyautodiscovery 'Ethernet 2' Auto Proxy Discovery: Off $ networksetup -getautoproxyurl 'Ethernet 2' URL: http://earl.local/cgi-bin/proxy.pac Enabled: Yes So, there you have it. For a workflow to use the proxy, it needs to call networksetup up to 33 times and then to download and parse the proxy.pac file (which is JavaScript). Or Alfred could make a trivial Foundation call and set the http_proxy and https_proxy environmental variables, which are automatically used by most network libraries (Ruby's, Python's, cURL etc.). Seeing as my feature request got zero response, most importantly from Andrew, a simple Foundation program that can get the system proxy and return it (or set the appropriate environmental variables) sounds like an ideal candidate for the bundler.

You'd be much better off using a language that can parse JSON, like Ruby or Python, than trying to make sense of it in bash. I wrote a Python library for Alfred that should let you do this in very few lines of code. Check out this example, which reads JSON from Pinboard's API and displays that in Alfred. I think that's about 80–90% of what you need code-wise to get started and it's only about 10 lines The library's tutorial is also all about grabbing JSON from a webservice and displaying it in Alfred, so that might be worth reading.

This is something that will bite you whenever you run a script via an OS X app and not directly in a shell. All apps (and by extension anything they launch) use launchd's environment (as that's the root process). In the case of a workflow, I'd recommend against sourcing your own ~/.bashrc (or whatever) unless you're sure you're never going to want to distribute the workflow. Even if it's, say, something that's only for developers who are guaranteed to have the environmental variable set, they might use zsh, not bash… There are ways to get around some of the limitations (such as LANG and LC_* vars not being set or set to "C") by getting OS X's environmental settings with defaults. For example, you can get the system language(s) with: defaults read -g AppleLanguages In other cases, you just have to ask the workflow user to provide the necessary information

No idea what's causing that, tbh (it works perfectly for me). Have you tried updating VLC?

It's child's play compared to the rest of the workflow. Very impressive stuff! You just need to change the Keyword to a Script Filter and use wf.add_item() and wf.send_feedback() instead of print(). Here's the hacky wrapper I made to turn it into a Script Filter. Lines 26, 28 and 31 are the important bits, the rest is just boilerplate: from __future__ import print_function, unicode_literals import sys from StringIO import StringIO from workflow import Workflow, ICON_ERROR from date_calculator import main as other_main from date_format_mappings import DEFAULT_WORKFLOW_SETTINGS def main(wf): # Replace sys.stdout to capture the script output stdout_orig = sys.stdout sys.stdout = StringIO() # Run the script and grab the output other_main(wf) result = sys.stdout.getvalue() # Put sys.stdout back together again, so wf.send_feedback() sends its # output to the right place sys.stdout.close() sys.stdout = stdout_orig # Add error/output to list of results if result.startswith('Invalid '): wf.add_item(result, valid=False, icon=ICON_ERROR) else: wf.add_item(result, 'Copy to clipboard', valid=True, arg=result) # Send XML output to Alfred wf.send_feedback() if __name__ == '__main__': wf = Workflow(default_settings=DEFAULT_WORKFLOW_SETTINGS) sys.exit(wf.run(main)) Here's how to make a Script Filter with Alfred-Workflow (you should probably skip straight to the section on Actions), and here are the docs on add_item(). You need to set a value for arg and valid=True in add_item() to make a result actionable. I just used one of the system icons supported by Alfred-Workflow for the error message.

Very nice indeed. I had no idea you could play YT videos in VLC. FWIW, you should select the "Double Quotes" and "Backslashes" escaping options in your Script Filters or things will break if someone enters " or \ in a query.

If I've understood you correctly, you want to pass two different values to two different actions at the same time. Alfred can't do that natively, so you can either bundle both your values together in arg and split them again afterwards or save one of the values to a temporary file and read it back from there.

What I usually do is keep all the code in an external script that accepts command line options, e.g. --list or --config or --open-help or whatever. Then each keyword is linked to a "dumb" Run Script that calls the external script via bash with the appropriate command, e.g.: /usr/bin/python myscript.py --search "{query}" or /usr/bin/python myscript.py --config It's still bit clunky, but that's probably the best way to do it given the limits of Alfred's workflow execution model. It's also more explicit than performing some keyword-based magic in your script.

Like he said, you probably need to check the settings. For whatever reason, the default date format in the workflow is "dd-mm-yy", not "dd.mm.yy" as in the description…

Very nice. Have you thought about making a Script Filter, so that you get the result/error message live? Kinda like this:

I meant with the GUI, not with Terminal. I know how to allow command-line apps. Can I get the Network Preference Pane to work that way?

I have my own fork of it. Some of my workflow descriptions have < and > in them, which was breaking the HTML, so I fixed up the generation code.

If you want to do that, you need to parse the info.plist in each installed workflow and grab the relevant modifiers and text. Shawn has done all the work of figuring out which code is which key in his Workflow Help Workflow, so if you dig through the source code of that, you'll be able to see which crazy number means which modifier keys.

You can't just leave it at that, you sod. How????

Alfred doesn't use your shell environment, which is what you see when you run locale or echo $LANG in Terminal. The workflow takes its default locale from your system settings with defaults read -g AppleLanguages (it grabs the first result). On my system, which has the preferred language set to "British English", I get: ( "en-GB", de, en, fr, "zh-Hans", "zh-Hant", ja, es, … … … ) Either change your Preferred languages in System Preferences under Language & Region so that "British English" is at the top, or append lang=en_GB to each of your formats, e.g: dateadd %x lang=en_GB will give you 19/06/2014. The Region you have set in Language & Region is ignored, as a lot of users have it set to where they live but have their system set to use English/British English. This results in unusable locales like en_DE or de_IT.

I've updated the workflow so you can ⌘+↩ on the "No translations…" error to go to the website. I've also changed it to always show definitions regardless of language (previously, they had to match the destination language). Regarding examples: no, it's not possible to show them in Alfred, as the Glosbe API does not provide examples.

I've never actually used it on a Mac, as I rarely do things in the Terminal that require sudo (I use Homebrew to install most software). Or does that also allow you to install stuff/change network settings without your password? That would be awesome!

That was my first thought (keep the locate database updated), but it ultimately isn't really viable because it takes ages to update and you can't be running it every 15 minutes in any case, and you also want newly created files to show up in Alfred in a timely fashion (say a couple of minutes at the very outside). I think the current implementation is an acceptable hack solution: You can add a specific folder to be searched with find, and if it turns out you're rarely adding new ST project files to it (which is pretty much always the case for me), you can delete that folder from the configuration and just rely on the results from locate instead (which will have picked it up by this time). At any rate, I'm very glad I fixed the workflow, as I added another couple of ST project files to hidden directories yesterday. Sod grubbing around in the filesystem like an animal. The /etc/sudoers tip is an all-round amazing thing that everyone should know. I only found out about it a couple of weeks ago, and am gutted I didn't learn it sooner. To think of the amount of time I could have saved typing in my bloody passwords. I now use it for apt-get on all my Linux machines. It might be different on OS X, but on Linux in any case, you still have to prefix the command with sudo, you just don't get asked for your password.