You can grab them individually on the Github repo or my download page. Or, just download them all in one go.

10/31/11: Updated to work with Growl 1.3 (MAS version).

TL;DR: If you want to use Growl notifications in your AppleScripts without causing problems for people who don’t have it installed, feel free to use this code.

For anyone who writes AppleScripts that use Growl notifications, the problem is familiar: if a user doesn’t have Growl installed, the script throws a fit when they try to run it. Specifically, at load time, the AppleScript interpreter looks for all the applications listed in the script to retrieve their scripting dictionaries, and if it can’t find any of the listed applications, it asks the user where to find it:

This can be frustrating for users who don’t have Growl installed: either they don’t know what Growl is (and therefore have no idea what to do in this situation), or they actively prefer not to have Growl on their system. In neither case do you want to force users to install Growl.

Although others have written about this issue—including a couple solutions that work—I still spent a lot of time and frustration trying to work through the issue and thought it might be helpful to post a survey of different methods that don’t work—and why.

Method one (bad): Growl, straight-up

Pros: Elegant, simple, as Growl intended. Cons: Script chokes on Growl-free systems.

The simplest solution is to call Growl using the intended syntax, ignoring users who don’t have Growl installed. The code is straightforward and easy to understand:

But if the point of your script is to simplify a task, it’s not very helpful to publish something that won’t run for those who don’t happen to share your idea of a pleasant notification experience.

And you probably don’t want to maintain two versions of the same script.

Interlude: Detecting Growl

To support both Growl-enabled and Growl-free systems, you need to detect whether Growl is installed before deciding what to do. For that, best practice¹ seems to be to first check whether Growl is running:

Then, if Growl isn’t running, check if it’s installed, try to launch it if so², and run the alternative notification if not:

Method two (bad): string encapsulation

Pros: Used to work; doesn’t choke on Growl-free systems. Cons: No longer works with Growl.

For a long while I used a very simple method that encapsulated Growl statements in a string variable, which prevents the interpreter from choking on systems that don’t have Growl installed:

Unfortunately this method no longer works when Growl is installed:

So that’s out.

Method three (bad): growlnotify

Pros: Elegant, doesn’t choke on Growl-free systems. Cons: Doesn’t work unless growlnotify is installed.

Another method is to use the growlnotify utility that ships with Growl Extras, and call it via a shell script:

But growlnotify isn’t part of the base Growl installation, so for Growl users who don’t have the tool installed, it won’t be obvious why the notification doesn’t work.

Method four (good): osaScript

Pros: Works for Growl users, doesn’t choke on Growl-free systems, uses standard AppleScript syntax. Cons: Verbose and unsightly.

The first method I found that actually works in 2011, described by elasticthreads, is to encapsulate the entire Growl-facing script as its own (perfectly quoted) string, and run that using the shell tool osascript:

I didn’t want to hardcode the notification parameters, and with all the quoted stringiness, extracting them required writing a method for converting an AppleScript dictionary to string form. Here’s my complete version of this method:

This method doesn’t choke on Growl-free systems, uses standard (though obscured) AppleScript syntax, and works for the Growly. It’s quite a lot of code, though, and isn’t very pretty.

Method five (good): AppleScript literal syntax

Finally—hats off to Dave Nanian for this method—AppleScript has an obscure literal syntax that can be used instead of standard syntax. In brief, literal syntax is a way of describing statements in guillemet-enclosed events and classes. This is what the above code looks like in literal syntax…

N.B. While literal syntax doesn’t require encapsulating the app name in a string variable, you should do this for two reasons. First, if the application name is used, the interpreter will try to find GrowlHelperApp, thus choking on Growl-free systems. Also, Script Editor will try to convert the code to normal syntax, which you don’t want if you’ve gone to the trouble of crafting this version. Note also Nanian’s warning to use tell my application, not tell application.

This method won’t choke Growl-free systems as long as you don’t run the code; make sure you include a check to see if Growl is installed before running this code.

All tedious things must come to an end

Giving Apple the benefit of the doubt, I’ll make two assumptions:

1. It’s generally important to have access to the scripting dictionaries of applications referenced in your script.

2. Growl is an edge case in that it’s simultaneously useful to include in a script but superfluous to the script’s execution.

But it’s a problem that people spend so much time coming up with workarounds for such a seemingly straightforward problem. If you have any other methods for dealing with the “Growl not installed” scenario, I’d love to hear them.

You can download a paste-and-go version of the code (which includes both functioning methods) here, or click here to open it in your script editor of choice³.

1. Much of this is gleaned from discussion and examples posted at the OmniGroup and DEVONtechnologies forums. I think the current version is most similar to one from Rob Trew.↩

2. In theory, you should be able to proceed without explicitly seeing if Growl is running/trying to launch if not, because calling tell application "x" will cause it to launch if it’s not already running. However, there was a time that Growl would crash frequently (I once measured one Growl crash every 7-8 activations), so checking for a successful launch was one way to ensure consistent behavior. Growl has gotten very stable, so this shouldn’t be a problem, but it’s cheap and fast to run the check so I keep it in.↩

3. Hat tip to Don Southard’s handy AppleScript-encoding service, which created the “open” link. ↩

property volume_multiplier : 0.8

tell application "Airfoil"
    set all_speakers to (get every speaker)
    repeat with this_speaker in all_speakers
        set curr_volume to get volume of this_speaker
        set (volume of this_speaker) to (curr_volume * volume_multiplier)
        if (volume of this_speaker) is 0 then set (volume of this_speaker) to 0.1
    end repeat
end tell

I keep two copies of this script (“Airfoil Volume Down” and “Airfoil Volume Up”) bound to ⇧F10 and ⇧F11, respectively, to match the volume keys on my keyboard.

If I ever update them, I’ll do so over on Github.

Download: Airfoil Volume Down and Airfoil Volume Up

This behavior makes sense, on one level level: just sort everything by Due date and you can see when things are planned. But every time a date isn’t met, it has to be pushed back, creating the need for most of my date-related scripts.

Worse, indiscriminate use of Due dates dilutes their value and undermines any task-planning system.

Need to pay a credit card bill today? It’s lost in the mess of other things that are artificially “due” today, and that red Due badge is no longer a respected indication that something needs to happen today.¹

But there’s a better way.² Just use Start Dates to plan what you think you should do, and reserve Due Dates for things that actually have to get done. (To keep this straight, I use a “Due” perspective to show what’s actually due, and a “Do” perspective to show what I’m planning to do.³)

The benefits of this approach are enormous. Things that actually need to happen don’t get lost in the shuffle, and (using time estimates) you can work with more realistic expectations of what can/should happen in a a day.

But switching to this workflow also required re-tooling my scripts, many of which focused on Due dates.

So, as of today, all my OmniFocus scripts default to a Start-based workflow. Here are some of the major changes:

• Today, Tomorrow, and This Weekend all set the Start date of selected tasks by default.

• In addition to pushing back due dates of tasks, Defer now has the option to act on un-timed tasks by pushing their start date back by the given number of days. (This option is on by default.)

• All scripts now work when launched from the OmniFocus toolbar.

• Scripts no longer fail when an OmniFocus grouping header is selected.

• All scripts reorganized for performance and clarity.

You can continue these scripts with a Due-based workflow, of course: this is a matter of changing a single setting in each script.⁴ But if you’re successful with a Due-based workflow, you have much more discipline than me.

Download the lot of them here. (And as always, let me know if you have any problems with them.)

1. Lest anyone complain of the cost of OmniFocus: I’m sure I’ve paid more money to my credit card company in day-of-due-date payment penalties than I have to the OmniGroup. ↩

2. Thanks to David Sparks and Benjamin Brooks for the insights that led to this realization. I mentioned this in a little more detail here. ↩

3. Here are the settings for my Do perspective:
   
   
   … and here are the settings for my “Due” perspective:
   
   
   Both live in my toolbar for easy access.↩

4. For example, in the Defer script, there is a line: “property snoozeUnscheduledItems : true. Simply open the script in AppleScript Editor and change “true” to “false” to switch this setting. If you have any problems, feel free to email me. ↩

Here’s a script to sum the total time of selected items in OmniFocus. Just select some items, fire it off and see how overcommitted you are.

Download it here.

Aug 2011 Lion update: the script works but is quite slow in Lion (it’s zippy in Snow Leopard). I’m looking for a workaround, but this appears to be a Mail.app bug.

TL;DR version: Archive Mail messages with a single keystroke:

1. Download this script and Fastscripts (free for up to 10 hotkeys)
2. Move the script to ~/Library/Scripts/Applications/Mail/
3. Set your hotkey in Fastscripts (Using a letter key is possible but not recommended. Try another character like `\/=- or an F-Key.)

The script will then move selected message(s) to a folder named “Archive”.

More information:

Existing shortcuts to file messages in Mail.app get you down to two or three keystrokes, but that just isn’t good enough for someone who has tasted the sweet, sweet bliss of single-keystroke archiving in Postbox or Gmail.

In my original reply to this superuser thread, I suggested using an AppleScript to move selected messages to an archive, and triggering the script using a single-key shortcut using Fastscripts. That script is simple and straightforward, but it has a major shortcoming: it leaves you hanging with no next message selected, so you have to manually select your next message. Not ideal.

My new script archives messages with a bit more smarts. Here’s what it does:

• If a mailbox is in the foreground, the script moves selected messages to the folder named “Archive” and selects the next available message. Boom.

• But you don’t want to accidentally archive messages whenever you hit your archive key. If the frontmost window isn’t a mailbox, the script will ignore the archiving functions and (optionally) type some text wherever you are. This is useful if you use a single key to trigger the script; without this function, you would never be able to type that key into a mail message because it’s intercepted by FastScripts before getting to the Compose window.

For interested scripters, here were some challenges:

• Select next message: The solutions I found online select the next message by sequential Message ID, which usually means that it only works if your mailbox is sorted by Date Received. Using visible messages gets messages in the order in which they’re displayed. Watch out, though: if message threading is turned on, the top-level thread item is not selectable. See my workaround in the script.

• Enter the keystroke that was captured: Merely telling System Events type the character that triggered the script will trigger the script again, resulting in a virtual infinite loop. I used a paste routine to work around this.

That’s it… happy archiving!

22 Mar 2011 update: fixed bug that caused selection to be lost when only the topmost message in a mailbox is selected.

In concept, the script really lets you to set start/due dates based on a relative weekly schedule. Simple modifications include:

• Changing your “weekend” to a different day/time range is as simple as modifying the settings at the top of the script. You could easily make a copy for “this week”, “next week”, “next Friday”, “next Thursday from 4:00-6:00″, etc.
• Un-commenting one line will bump it forward a week (think: “next weekend”).

Download it here

Download it here

Update: for those interested, here is a version that lets you change the context as well. I don’t personally use this version so please let me know if you have any issues with it.

Why would you need such a thing? One reason is that Fastmail lets users specify an infinite number of aliases which they can give to an infinite number of websites (and subsequently block, if an infinite amount of spamming ensues). Mail.app doesn’t offer a good way to change your reply address, but replying from the Fastmail web interface does the trick nicely. (Thunderbird users can use the Virtual Identity plugin for this as well.)

Here’s the script:

--Searches for the messages selected in Mail.app using the Fastmail web interface
--By Dan Byler (http://bylr.net)

tell application "Mail"
    try
        set selected_messages to selection
        set remaining to count of selected_messages
        set the_url to "https://www.fastmail.fm/mail/?MLS=MS-*;MSS=!MB-*;SMB-CS="
        repeat with the_message in selected_messages
            set remaining to remaining - 1
            set message_id to the message id of the_message
            set the_url to the_url & "msgid%3A%22" & message_id & "%22"
            if remaining > 0 then set the_url to the_url & "%20OR%20"
        end repeat
        set the_url to the_url & ";SMB-SearchAll=on;MSignal=*P-1"
        open location the_url
    end try
end tell

Or download it here.

This long-overdue update includes two changes:

• adds the option to archive all items in a specific date range
• fixes an issue when a news item’s description is not available

Grab it here.

I’ve added two more scripts to my OmniFocus repertoire: Today and Tomorrow.

As one might expect, Today sets the “Action Date” of selected item(s) to the current date, and Tomorrow sets the action date to the next date. (By default, the Action date is the Start date, but you can switch to use the Due date if you prefer.)

Why might you need this? A few days of ignoring OmniFocus is enough to make any date-sorted view overwhelming. My Defer script is one method to deal with these items: defer them by a day, a week, etc. But sometimes you just need to set these items to today. Or tomorrow.

As with Defer, these scripts work with any number of selected tasks.

If you use the default “Start” mode:

• The Start date of each selected item is set to the current day
  • If an item has a previously assigned Start date, its original time is maintained. Otherwise, the start time is set to 6am (configurable in the script)

If you use “Due” mode:

• The Due date of each selected item is set to the current day
  • If an item has a previously assigned Due date, its original due time is maintained. Otherwise, the due time is set to 5pm (configurable in the script)
• If an item has a Start date, it is moved forward by the same number of days as the due date has to move (in order to respect parameters of repeating actions)

Putting it all together

I’ve set my keyboard shortcuts for Defer, Snooze, Today, Tomorrow, and This Weekend to ctrl-d, ctrl-z, ctrl-t, ctrl-y, and ctrl-w, respectively (using FastScripts), so shuffling tasks couldn’t be easier. Use cases:

Catching up after holiday: Select all overdue tasks, hit ctrl-t to bring them current. Then snooze or defer the ones you won’t get to today.

Planning today’s tasks: Select your tasks and ctrl-t them into the day’s queue. Planning tomorrow? Use ctrl-y instead.

Download them here

Thanks to Seth Landsman for his role in inspiring my Today script. His version is very similar but doesn’t quite match the defer logic I need.

Usage note: some items inherit due dates from their parent task or project, but don’t actually have due dates themselves. This script ignores those items.

Here’s an AppleScript that “snoozes” selected OmniFocus items by setting their start date to a future* value. These items will then be unavailable (and out of sight in views showing “available” items) until the snoozed start date.

Usage:

1. Run the script with one or more items selected in OmniFocus

2. Choose how long you would like to snooze the items (in # of days)

The script will then set the start date of selected items to the current date + the number of days selected in step 2. For example, snoozing with the default value of 1 day will set the tasks to begin at 12:00 AM tomorrow.

Finally, if you have Growl installed, the script will display a Growl confirmation.

I highly recommend initiating the script from a third-party launcher such as FastScripts or Quicksilver. This will prevent delays within the OmniFocus application due to Growl bugs.)

Download it here.

* This doesn’t have to be a future value. Choosing 0 as the snooze value will set the start date to midnight today; choosing -1 will set the start date to midnight yesterday.

Here’s a script that attempts to subscribe to a full-text feed of the current subscription in NetNewsWire. It does this using EchoDittoLabs’ excellent FullTextRSS service.

To use, select a headline or subscription title in NetNewsWire and run the script. The full-text feed will appear in your top-level items.

Thanks to harvey.nu for the URL encoding routine. The script worked without the routine but it seemed safer to include it.

[Updated 2/22 with change suggested by Pascal.]

Download a copy here.

The updated Defer script for OmniFocus is ready. Changes include:

• Bug fixes to make the script more reliable, particularly when deferring multiple items.

  • For most of these I’m indebted to Curt Clifton, who made the most critical bug fixes on the OmniFocus forum. (If you use OmniFocus, his scripts and tools are invaluable; be sure visit his site.)

• The default action now defers both start and due dates.

• Notifications code has been rewritten to make the script friendly for machines without Growl installed.

  • While testing, I discovered that GrowlHelperApp crashes on nearly 10% of notification calls. To work around this, the script now checks to see if GrowlHelperApp is running; if not, the script launches it. If Growl is not installed or can’t launch, the script displays a generic notification of the defer results.

If you experience delays with the script, it’s almost certainly an issue with Growl, not OmniFocus. This is much less of an issue if you launch the script via a third-party utility like FastScripts, because any Growl-related delays will be absorbed by the script launcher, not OmniFocus. If you primarily invoke the Defer script from your OmniFocus toolbar, you can always disable alerts to speed things up. To do this, simply open the script in Script Editor and change property showAlert to false.

Download it here.

Enter DEVONthink Pro, a highly reviewed research tool/information manager.

The NetNewsWire > DEVONthink bridge is a logical one, so it’s no surprise that DEVONthink Pro comes with preloaded scripts to archive information directly from NetNewsWire. (Sorry, DEVONthink Personal doesn’t include scripting support.) But the feature I really needed – the ability to archive entire RSS feeds into DEVONthink – is not included in these scripts.

To fill this gap, I wrote a script to archive entire newsfeeds (or subsets thereof) to DEVONthink Pro.

This script saves items from your selected feed (or folder of feeds) to DEVONthink Pro as web archives, with the following options:

• From the selected feed, folder, or smart folder, save:

  • All items

  • Flagged items

  • Unread items

  • Read items

  • Date range (archive all items within a specified date range)

• Archive options:

  • Feed saves just the content of the news item (typically the best option if the site provides full-text feeds)

  • Site saves the content of the item’s target website (this should be the whole article – particularly useful if the newsfeed is truncated)

  • Site/Print goes to the item’s target website and looks for a link that includes the string “Print”. If one exists, it saves the print-ready page to DEVONthink. If none exists, reverts to “Site” behavior.

• Perform post-archive actions: mark read, unflag, or do nothing. This action occurs after DEVONthink has archived the article, so you can see archive progress in action and ensure you don’t double-archive an article

• Optional: introduce a random time delay between archiving articles if using “Site” or “Site/Print”. (Useful if the site you’re reading from has countermeasures to prevent content scraping. Read: if they’re trying to keep you from saving their content for later use.)

My personal workflows for this script:

• Flag items of interest from all newsfeeds. Then run this script periodically to import all flagged items into DEVONthink. Archive target: Flagged items (feed); Post-archive action: Unflag.

• Save full-text content of a magazine I subscribe to but don’t want to keep hard copies of. Run this script every week, when the magazine’s RSS feed is updated. Archive target: unread items (Site/Print); Post-archive action: Mark as read.

Get the script here.

Update 2008-08-12: Added an additional Growl-free script to the download for users who don’t have Growl installed. The only difference is that the lines referencing GrowlHelperApp are commented out. Same download link applies.

Update 2010-05-26: Fixed a problem encountered when news items don’t have a description. Added an option to archive items from a specific date range. The download link has been updated.