#alfred.app

There is one thing one must concede to the Windows people: for all the convoluted mess they made out of their file manager (and I could digress, at length, on the semantics of calling it “Explorer” when Apple’s own is called ”Finder”), the overburdened web browser “just for files, ya know” metaphor does at least hand you a refresh button. Admitting that network shares might not always be automatically up to date, network connections, especially over such, ahem, flaky protocols as WebDAV, being what they are, is one thing that I would not mind Apple stealing.

The funny thing is: Apple already did, but they hid that feature away in the one corner of OS X even the boldest rarely dare to venture: AppleScript. Of course, intrepid souls have discovered it, and of course, there is a very nice utility to integrate that feature into Finder: Söderhavet’s Refresh Finder. Drag the app into Finder’s toolbar, and you are set.

Unless, like me, you find it annoying that the icon that goes to such pains to masquerade as a Finder button, new style, does neither match the proportions of the other buttons, nor get grayed out when Finder windows are in the background[1]. Or if you would like to use a hotkey instead of clicking toolbars. Maybe with an option for choosing if you only want to refresh the frontmost or all Finder windows? An Alfred command too, maybe?

OK. Done.

I’m not sure how to describe my current situation: threading water in a professional quagmire while I watch the Yak shavings of my side projects idly swirl by me might come close … if it doesn’t get me put away , that is. Never mind.

So having had a bit of entirely unexpected free time in the shape of a family free Easter holiday, I thought I’d have a closer look at Alfred 2’s new workflows. Alfred has been my go to launcher tool since its inception (or about), and version 2 has added a powerful semi-visual scripting system for building extension workflows. Think Automator done right for the keyboard crowd.

Workflows have been popping up right and left[1], including whole frameworks to create them easily in languages like PHP[2], Python[3] or Ruby[4], some of them truly amazing, and as the update to version 2 has done away with some stuff in favor of them, notably the Automator extension I used to dial my iPhone from my Mac using the very nifty PushDialer, I have been exploring. Alas, the only PushDialer extension I could find was rather … simplistic. So I improved it. A bit.

The result is an Alfred workflow called “Dial with PushDialer”. It has the basic trimmings, i.e. a Contacts custom action you can wire up to phone numbers in Alfred’s contacts viewer, a dial keyword and keyboard shortcuts to handle stuff selected in OS X applications. It should handle most any phone number format you throw at it well, including those with tel:// protocol prefixes, courtesy of two lines of Ruby. It notifies you when it manages to pass a phone number to PushDialer and it will beep when stuff goes wrong. All good and nice.

The really interesting part is in a feature of Alfred workflows called script filters. These allow you to provide results to a query you type in Alfred right in Alfred’s result window, instead of redirecting to some external search page or app. It’s close to magic once you figure it out (basically, you have to construct a plist-ish XML file of results you return to Alfred ), and that is what the keyword call does: instead of making you search for a contact, then go to its number, and action that, you can just call name in Alfred and you will get either the home, work, or mobile phone number of any contact whose name or company name matches your query right in the result window. Action that and PushDialer will dial it for you:

If you want to target home, work or mobile phone numbers directly, just use callh, callw or callm . The results are courtesy of the contacts utility by Shane Celis and some minor bash fu by yours truly[5].

There are a few interesting tidbits I figured out on my way: how to use <[CDATA[]]> tags to Not F… Up The XML Way™ and how to provide a fallback to Alfred’s default search when there are no results to display. If you want the know more, have a gander at the source of the numbers script – the workflow is up on GitHub.

If you just want to install the workflow, here is your ticket. Did I mention it supports Alleyoop, the workflow autoupdater by Daniel Shannon? Well it does.

Have fun.

There is an attempt at a central repository at http://www.alfredworkflow.com, but for the time being, your best bet is still scouring the Alfred Forums and GithHub.  ↩

ugh  ↩

meh  ↩

the alfred-workflow gem. Can you tell I’m partial to Ruby?  ↩

Use Alfred.app and install this attached AlfredExtension.

After installing, you are presented with this:

To break this down, there are really just four things to do  in this method of getting a selected screen estate on your server and on your clipboard as a direct, pasteable URL:

Use screencapture to capture a selection with -is. Tell it where to save the resultant screenshot and finish the path with {query} (Alfred passes this from the Alfred toolbar)

Use scp to send the resultant file to your server

Use echo to print out the resultant URL, (server/{query}), copy it to clipboard with pbcopy

And finally, optionally, either use rm to permanently delete the image from your folder of choice, or keep it commented away in the extension  by leaving the --  in place.

Adjust the user/server -names accordingly. I run it via 'ul imagenameIwant.png', f.ex.