On the other hand, I wrote an alternative years ago, called Usable Keychain Scripting. Its main advantage over Apple’s implementation is that it is (or at least, was) enormously faster. Today I updated the app to be 64-bit compatible and to fix a pernicious bug in which the password value returned for a keychain item would sometimes have garbage appended to the end of it.

Download Usable Keychain Scripting 1.0b4

This is not a supported product, and your success with it may vary. But it has been very handy in the past for me, and hopefully it will come in handy for you if you need to script the keychain.

Downloads used to be shown in a completely separate window, which could be toggled using the keyboard shortcut Cmd-Opt-L. In Lion, they appear in a popover panel attached to the toolbar of whatever browser window you happen to be using. Unfortunately, there is no keyboard shortcut to toggle the appearance of this popover.

Using FastScripts and a simple UI Scripting script, I was able to restore this functionality, so that Safari on Lion toggles the panel using the familiar Cmd-Opt-L shortcut.

Download the “Toggle Downloads Popover” script

Download the script, and copy it to:

[Home] -> Library -> Scripts -> Applications -> Safari

Here it will show up in FastScripts (or Apple’s script menu) only when Safari is the front-most app. You can also assign it a keyboard shortcut, like Cmd-Opt-L, that will only be active when Safari is active.

Important: If your Mac is not configured to run with English as the primary language, the script will not work without a minor adjustment. You will need to open up the script and change the text string “Downloads” to the language-specific description for the downloads panel in your language. For example, to make it work with Safari running in Spanish, you would change the string to “Descargas”.

I find it very useful to be able to popup the panel when I am checking on the status of a long download, or when I want to check quickly whether I already downloaded something I had intended to. Hope this script works well for you as well!

The way I use Twitter is to leave one of these client applications running in the background, with all the notification settings set to off. I still check it quite often, but it’s on my terms. If I get deep into concentration working on some bug, chatting with a friend, or or watching a video, I don’t want Twitter interrupting me.

Twitterrific was the first desktop client I used, and I can’t remember whether it was the default choice or if I picked it, but I got in the habit of using the global keyboard shortcut Cmd-Ctrl-T to toggle the window’s visibility. When I tried other Twitter apps, I made a point of setting the preference in that app to match the same shortcut.

Eventually I tried an app that didn’t support a setting for a global keyboard shortcut, so I had to write a script to do it for me. It occurred to me at some point that I could write a single AppleScript to handle the toggling of visibility regardless of which app I was using.

Download “Toggle Twitter”

The script logic is pretty simple: given a list of common Twitter app-names, is one of them running? If so, toggle it. If not, launch it. If you’re using something else, just add it to the list, and it should work perfectly.

I used FastScripts to hook this up to the global shortcut Cmd-Ctrl-T because it matches my historic muscle memory, and well, T is for Twitter.

Georg C. Brückmann chimed in with a semi-solution, which is a URL template you can use to jump directly to a PayPal transaction by ID. Take the root PayPal URL for your country, and add “vst/id=” followed by the PayPal transaction ID. In the United States, this leads to a URL like: https://www.paypal.com/vst/id=1234.

It’s sad to say that remembering a static PayPal URL and pasting in the transaction ID in the magic location is indeed easier than navigating PayPal’s slow and awkward transaction history UI. But it could be even easier with a little automation.

Jump To PayPal Transaction ID is a simple AppleScript that prompts you for a transaction ID, constructs the desired URL, and opens it in your default browser. If you don’t live in the United States, open the script in AppleScript Editor and alter the template URL contained within it.

I put this in my Safari-specific scripts folder:

[Home] | Library | Scripts | Applications | Safari

So it’s available from FastScripts whenever I’m in Safari. Problem solved.

If you’re not familiar with Google Quick Search Box, it’s basically a Quicksilver-style launcher, which can open all manner of documents and also do Google searches for whatever you’re typing, all at once. With the addition of Martin’s FastScripts plugin, it also magically gains the ability to directly run FastScripts scripts.

So if I bring up the quick search box and start typing the name of one of my scripts, it shows up instantly:

Significantly, this is more meaningful than simply knowing about where the scripts are located, and running them. Martin mentioned to me that he was taking advantage of my “API” for accessing and running the scripts. Huh? What? I don’t have an API, do I? Oh yes, but of course! AppleScript itself! Martin used the fact that FastScripts exposes AppleScript access to its library of scripts, and for executing those scripts in the context of FastScripts. So when you select and run a script from the GQSB, it runs exactly as it would if you selected it from the FastScripts menu itself.

A clever piece of work by Martin that takes unexpected advantage of these hooks I put into FastScripts. If you use both FastScripts and GQSB, you might want to check his project out!

I store most of my iTunes tracks in Apple’s AAC encoding format, but from time to time I find it useful to convert some tracks in my library to MP3 format. While AAC is convenient and works on my iPod, iPhone, etc., I have to concede that MP3 format is a little more universal.

In the iTunes “Advanced” menu you’ll find a convenient conversion item, which lets you convert the encoding of a selected song file to whatever your default import encoding is. The problem is, since I’m always importing as AAC, the only option it gives me is to convert to AAC:

To use iTunes to convert a song to MP3 format, I would have to open up Preferences, click the Import Settings button, and change my default encoding choice to the MP3 encoder. Then I would have to close preferences, do the conversion, and then preferences and switch my encoding choice back to AAC.

YUCK!

AppleScript to the rescue. Because iTunes exposes an attribute “current encoder”, and because AppleScript exposes a command “convert”, I can do all the mucking about behind the scenes in a quick-running script that performs theses steps:

1. Save the current encoding setting.
2. Switch to the MP3 encoder.
3. Convert the selected songs.
4. Set the encoder back to whatever it was

Download the Convert to MP3 script. Install it in [Home] -> Library -> Scripts -> Applications -> iTunes. It will show up in FastScript’s iTunes-specific section, where you can assign a keyboard shortcut if you like.

Now when I want to convert songs to MP3 format, I just select them in iTunes, and press the keyboard shortcut I assigned to the script in FastScripts:

The conversion happens immediately and my encoding preference is not disturbed.

I use iTunes all the time, but it hadn’t occurred to me how annoying this is. You’ve been fishing around in the iTunes store, or the Podcasts source, or Audiobooks, or any of the numerous other zones of the application. Then, you get the crazy notion to actually use iTunes to listen to music, so you jump to the search box and start searching. Bah! It’s not searching my music, it’s searching the App Store, or whatever. Now you have to go click the “Music” icon, and start your search again.

So yes, it would be handy to have a convenient shortcut to switch back to the Music source, and that is where my scripting utility FastScripts is particularly potent. It was a little tricky to deduce which magic scripting command would achieve the goal, but I think I figured it out:

tell application "iTunes"
	set view of (browser window 1) to user playlist 1
end tell

Save this as a script file in your home directory:

[Home] -> Library -> Scripts -> Applications -> iTunes

This is an “Application-specific” scripts folder for iTunes, meaning it will only show up when the iTunes application is actually active and frontmost. Now you can open up FastScripts (free for up to 10 shortcuts) and use it to assign a keyboard shortcut:

Now when I’m browsing iTunes, I just press cmd-option-M and it jumps instantly to my music!

I have a bunch of iTunes scripts that I find useful. Over the next few days I’ll be highlighting other convenient tricks I use to make iTunes a more useful application through its scriptability.

In the wake of his high profile MacHeist debut, Gus announced something new today which is decidedly less consumer-oriented (though if it takes off, it could certainly have wide-reaching consequences). JSTalk is Gus’s JavaScript-based answer to what he sees as outdated and clunky about AppleScript, Apple’s preferred scripting language on the Mac.

For starters, Gus’s JSTalk provides syntactic sugar on top of standard JavaScript in order to give it some comfortable Objective-C style conveniences. Then, he provides a teeny bit of source code that any application can embed in order to respond to incoming JavaScript commands. This results in a scenario where an Objective-C based application can easily expose its internals to other applications, so that a script written in JSTalk can control it from another application.

I’m excited about the idea of JavaScript taking a more prominent role in the scripting infrastructure of Mac OS X. In fact, about 9 months ago I wrote some challenging words about my opinion on the matter. Responding to Apple’s impressive enhancements to JavaScript in the context of WebKit:

I hold a soft spot in my heart for AppleScript. But I’m slightly more of a pragmatist than a romantic. If JavaScript is what Apple cares most about, and JavaScript is where massive performance improvements are going to be made, then Apple should leverage those improvements to the benefit of every desktop scripter.

Since then, Apple has given no indication of pursuing a system-wide infrastructure for JavaScript scripting. So in comes Gus Mueller with JSTalk, and solves the problem. Right? Well, sort of. Gus’s idea is very cool and clever given the constraints he’s working with. Namely, he can’t easily control how every application works, or how it interacts with the system and every other application. His solution is cool, and may even be worth adding support for to your application, but it’s not as cool as a system-wide, Apple-endorsed solution would be.

Michael Tsai makes some smart observations about JSTalk, also agreeing that it’s cool, but taking exception to Gus’s claim that getting away from the rigid structure of AppleScript’s XML-based scripting dictionaries is a good thing:

I think defining the object model, e.g. using XML, is a feature. Otherwise there’s no separation between the scripting interface and the application’s unstable internal interfaces.

Taking a closer look at Michael’s post, I think I could have avoided this somewhat long-winded post by starting simply with, “Yeah, what Michael said.”

Nice work, Shimone! It’s great to see examples like this. As I said, I think it’s nice the way MarsEdit hides much of its functionality away, but the flip side of that is of course that it can be difficult to realize its full potential. Blog posts such as Shimone’s do a good job of showing off its hidden strengths.

KUDOS to the WebKit team! When I last read about JavaScript performance, it was on Jeff Atwood’s substantial comparison of many browsers and their respective performances. At that time Safari already stood near the front of the pack, only being narrowly beaten by Opera in terms of overall performance.

I expect that unless other browsers have also been dramatically enhancing their JavaScript performance during this time, the SquirrelFish parser will put Apple’s WebKit far in front of the other major browsers in the market. At a time when JavaScript is being used more and more in web applications, the benefits of this advantage could be magnified into a noticeably superior user experience on many web sites.

What About AppleScript?

This announcement got me thinking about Apple’s scripting languages and where the most growth and progress is being seen. Here we have a dedicated product team, responsible for providing a scripting service more or less only intended for use within the context of a web page. Yet this team seems to have a stronger corporate charter for making progress than the AppleScript team, which is responsible for the language that provides system-wide scripting glue to both users and developers. JavaScript must be the single most prioritized interpreted language being developed within the walls of Apple. Yet AppleScript, an often-maligned proprietary Apple language, is still the system-wide standard.

As a variety of web technologies permeate the desktop (and other platforms such as the iPhone), JavaScript is becoming increasingly popular and well-recognized. While AppleScript is lauded for being accessible to naive users, it’s factual ease of use is becoming less relevant as JavaScript’s actual ease of use explodes. How is JavaScript becoming actually easier for users? By means of simple, forced exposure. Just as an awkward, text-based system such as HTML has become so dominant that many secretaries and construction workers are passably fluent in it, so are the majority of users who are likely to use scripting passably fluent with JavaScript.

Apple should make JavaScript its default scripting language.

There, I said it. It wasn’t easy, because I hold a soft spot in my heart for AppleScript. But I’m slightly more of a pragmatist than a romantic. If JavaScript is what Apple cares most about, and JavaScript is where massive performance improvements are going to be made, then Apple should leverage those improvements to the benefit of every desktop scripter.

It sounds like I just said “Apple should kill AppleScript,” but I didn’t. You see, the Open Scripting Architecture, on which AppleScript runs, is designed from the start to support multiple languages. Think of the “Open Scripting” part of the system as the part that lets a script tell another application to do something. The specific scripting language you use to accomplish the rest is really of no concern whatsoever. Two languages, such as JavaScript and AppleScript, can easily live side by side.

The idea of using JavaScript as a Macintosh scripting language is not new. Mark Aldritt of Late Night Software has for years published a plugin called JavaScript OSA which provides the functionality I’m talking about. Here’s a simple script in AppleScript to activate iTunes:

tell application "iTunes"
	activate
end tell

And here is the same action written with JavaScript OSA:

with (MacOS.appBySignature('hook'))
{
	activate()
}

It’s a little clunky, I’ll grant you. It’s a nuisance that in this incarnation, I had to use the old-style application signature code. But these cosmetic problems are easy enough to fix. If Apple provides its own JavaScript language layer for OSA, it could divert the majority of resources it currently spends on AppleScript. Instead of struggling to keep AppleScript “modern enough,” these fine engineers could instead devote themselves to fine-tuning the JavaScript experience for desktop scripting.

Apple is leading the pack in the development of an interpreted scripting language: JavaScript. It’s time to move on. Adieu, AppleScript.