Archive for the ‘AppleScript’ Category
While losing iWorks AppleScript support is anxiety-inducing, some great new features have been added to AppleScript in Mavericks that are pretty exciting. I’ve played a little with libraries and Notifications in the DPs, but haven’t incorporated anything into my scripts since
most a few of these features are not backwards-compatible on earlier operating systems.
Don Southard has a good article at MacStories outlining the latest stuff.
Apple has effectively killed AppleScript support in its latest versions of the iWorks apps. Probably not a surprise but a shock just the same. It’s not a surprise because AppleScript support in Pages.app et al has never been very glamorous. But I don’t have any doubts that the main consideration is the big part the iWorks apps play in Apple’s iCloud/iCloud.com stategy and the security ramifications thereof. Anything that touches iCloud is pretty much hands-off to AppleScript.
Still, it’s hard to sit helpless and watch AppleScript’s maddeningly sad and frustrating march to irrelevance as iOS usage inevitably overtakes OS X.
Inter-app automation on iOS. Now that would cheer me up. There’s hope, right?
With OS X 10.9 Apple takes security more seriously than it ever has. In this regard, Apple has added an additional level of security for apps that access the Accessibility API via “System Events”. Here’s how that new level of security may affect the way you use some AppleScripts downloaded from this site.
First of all: Some of my script applets (the ones with user interfaces) cannot run effectively while iTunes is in full screen mode. This is because only one of them, iTunes or the script, can be frontmost. So, when these scripts are launched they will detect and alert you if iTunes is in full screen mode.
To do this the script targets “System Events” to check for an accessibility property of the iTunes user interface indicating whether or not full screen is on. “System Events” is in the purview of Accessibility. If you’ve ever used GUI Scripting—to script key codes for example—you’ve had to set “Enable access for assistive devices” in the Accessibility pane of System Preferences. Well, as of OS X 10.9, this is no longer a global setting and must be set on a per-app basis.
There’s seems to be a bit of inconsistency with the way iTunes 11 displays playlist time information as DD:HH:MM:SS. Sometimes times are displayed in the Status Bar at the bottom and sometimes a decimal version will be displayed beneath the playlist’s name at the top of the browser. I can’t quite get a grasp on something like “7.6 days” though.
Here’s a script you can attach a shortcut to that will simply display a dialog box listing the name of the selected playlist, the number of tracks it contains, and the time of the playlist as DD:HH:MM:SS:
As I mentioned below, I had to fix a script to workaround a problem playing a playlist when only one track had as yet been copied to it, which prevented the rest of the subsequently added tracks from being recognized by MiniPlayer and Up Next; thus, only the first track would play. Similarly, if you were to play (the AppleScript command) any track in a playlist, the following tracks will not play because they haven’t been recognized by MiniPlayer and Up Next (”No upcoming songs”).
Doesn’t go good when Mini Player is empty:
You can play the playlist and everything’s OK. You just can’t initiate play of the entire playlist by playing one of its tracks with AppleScript.
Goes good and loads in MiniPlayer:
Additionally, I found that if the MiniPlayer was already loaded up with tracks, playing a track (via AppleScript) from anywhere would play that track and then resume with whatever is next in MiniPlayer.
Technically, you can’t open a playlist in its own window in iTunes 11, so the playlist window element is moot.
You can no longer designate an album of tracks as gapless. Thus, a track’s gapless property is now moot.
ERRATA: My title for this post is misleading. The gapless feature has not been lost. But the ability to manually change a track’s gapless setting has been removed.
This updated version features some iOS-inspired GUI changes, re-designed MiniPlayer, improved iCloud integration, improved search, and a revamped design of the iTunes Store.
I was inspired by this recent article by Dr. Drang on using TextExpander to insert the URL of Safari’s front document wherever you’re entering text. There might be some benefits to being able to get current information in iTunes with a TextExpander AppleScript snippet or two. Or, as I describe below, three.
In case you don’t know, TextExpander is a typing shortcut tool for the Mac whereby you enter a little abbreviated text and a predefined batch of text is inserted where you’re typing. One of its amazing features is its ability to fire AppleScript snippets the same way. TextExpander can’t accommodate hulking huge AppleScripts but it does allow for some pretty flexible ’scripting.
Before I get to the AppleScript part, here’s how to set up TextExpander:
I’ve been meaning to post this for the record. Shane Stanley has written up How Mountain Lion Changes the Rules for AppleScript at TidBITS. He explains how scripts and AppleScript applications can be saved in an uncompiled state. If you distribute or system manage AppleScripts and develop on Mountain Lion you really should be aware of these changes.