Triggers are great for summoning apps – if an app is not running, it launches, and if it is running, it activates. However, services such as Feedly provide their… services in web apps. A trigger to open a service’s URL can result in multiple duplicate tabs cluttering up the default browser.

To reduce tab-closing chores, the following script activates or, if necessary, opens a Feedly tab in the frontmost Chrome window:
tell application "Google Chrome"
activate
try
tell window 1
set _tabs to tabs
set _tabNumber to 0
repeat with _tab in _tabs
set _tabNumber to _tabNumber + 1
if URL of _tab contains "http://www.feedly.com/" then
set URL of _tab to¬
"http://www.feedly.com/home#my"
set active tab index to _tabNumber
return
end if
end repeat
end tell
end try
-- If no tabs contain the parent URL:
open location "http://www.feedly.com/home#my"
activate
end tell
No need to save the script – just grab it into Quicksilver, set ‘Run as AppleScript’ in pane 2, and hit ⌃⏎ to find the ‘Add Trigger…’ action.

The script can be modified to accommodate almost any URL.

AirPlay is one of the best features of Mountain Lion. YouTube becomes a proper TV channel, and iTunes music can be streamed away from tinny MacBook speakers.
However, first-world problems arise when a video is already fullscreen and the AirPlay button can’t be clicked, and hitting play on the keyboard doesn’t really save time because iTunes’ AirPlay icon needs to be clicked to stream audio.
Thanks to Doug Adams, I’ve been able to write a script that toggles AirPlay in iTunes 11.0.3 and upwards. I’m assuming one Apple TV that hasn’t been renamed. Check out Doug Adam’s posts if you have a more complex setup.
Subsequently, I was unreasonably annoyed to discover that iTunes’ AirPlay feature is separate from the rest of Mountain Lion, So I wrote another script that does the hard work of clicking the menubar’s AirPlay icon – even when a video is (and this can’t be done manually) fullscreen.
Save the scripts anywhere you like, and create triggers for them in the form ‘[script]⇥Run’. If anyone’s got a cleaner way of toggling Mountain Lion’s AirPlay feature, let’s hear it!
Is there a way to grab the iTunes track that is playing? Something like how command-g grabs the current Finder selection.
Sure! With the iTunes plugin installed, check ‘Currently Playing Track’ is selected in Preferences>Catalog>Quicksilver>Proxy Objects.

Make a triggger for ‘Currently Playing Track→Select in Command Window’, and you’re done.

Printopia is an excellent way to print from an iOS device. It costs some bucks, but it’s a lot cheaper than buying an AirPlay printer. Files needn’t go straight to a printer though. As files are routed through a Mac, Printopia also provides an option to open them in any app of the user’s choosing – including Quicksilver.
Go to Printopia’s System Preferences pane, click the ‘+’ icon, and then ‘Send to Application’ to add Quicksilver.
Select a document or image on an iOS device and find the Print button. Select ‘Send to Quicksilver’ from the list of printers, and tap ‘Print’.

The file will appear in Quicksilver shortly. Do with it as you will.

We don’t normally talk about the development changes we make under the hood for Quicksilver, but without our developers making awesome plugins, Quicksilver wouldn’t be what it is today.
Recently we’ve been working hard to make it as easy as possible for new developers to create plugins for Quicksilver. As a testament to this, you’ll see that the list of ‘developer changes’ in the changelog is almost as long as the ‘features’ and ‘fixes’ list for recent versions of Quicksilver.
For now, let’s skip past those changes (if you want to know more abou them, either check out their corresponding pull request on Github, or ask in the Quicksilver Developer Groups (see link below), and look at some of the bigger things we’ve done over the past years to give anyone and everyone as much help as possible in creating plugins.
Who ever said documentation wasn’t important?
Over the years, Rob McBroom (a Quicksilver lead dev) has meticulously compiled a comprehensive Plugin Reference on getting started with plugins, and an overview of what you need to define in a plugin’s Info.plist so that you (the developer of a brand new Quicksilver plugin) can get the most out of your plugin. The Info.plist has always been the tricky bit in creating plugins (here’s an example .plist file from the iTunes plugin to show how complicated things can really get), but Rob’s overview makes life so much easier.
If you ever get the smallest urge to create a plugin, this is where you want to start.
Discussed in the Plugin Development Reference is the XCode Plugin project template. This is a handy template (.xctemplate file) that you can drop into Xcode to make setting up a new plugin project much, much easier.

From the plugin reference, here’s the steps you need to take:
Quicksilver Plug-in.xctemplate to ~/Library/Developer/Xcode/Templates/Application Plug-inMake sure you take a look at the plugin reference though, as there are a few more steps and niggles that you’ll need to complete before you’re ready to go.
When the current development team jumped on board to save Quicksilver, documentation on existing plugins was few and far between. Comments in code were non existent, and things were just a right pickle, to be perfectly honest.
Things are much better now, with it much easier to dive straight into the code of one of the existing plugins to find out how something or other was done.
We’ve tried to make writing plugins as simple and bash-my-head-against-the-wall-free in recent months. Now, when writing plugins, you can define new QSObjects and Actions based on UTIs of objects. We hope to expand this further in the future by converting all Quicksilver ‘types’ to conform to the UTI API.
One of the most convenient feature of Quicksilver is the comma trick. Previously, developers would have to write two bits of code for each and every action (QSAction) depending on whether one or more than one object was selected (using the comma trick). Now you can use the same code and just iterate over an array of QSObjects (be it an array that contains 1 QSObjects or 10, it doesn’t matter). Here’s some code to show how easy it is to implement the comma trick in one of your plugins:
// 'dObject' is the 'direct object' sent to the action method from Quicksilver's 1st pane when the user executes your plugin's action
for (QSobject *eachObject in [dObject splitObject]) {
// do something with data from eachObject in the 'comma trick' list. e.g. email it, trash it, display it large type...
}
And there we have it, a quick look at developing plugins for Quicksilver. If there’s positive feedback about the post, and people want to know more, we’ll make sure to get a series of blog posts out from start to finish on creating plugins for Quicksilver.
Also: stay tuned… we’ll be arranging a Quicksilver code meet up in the not too distant future!
References: