3

I have a simple Ruby script that uses the rb-appscript gem to control iTunes, and now that I've updated to iTunes 10.6.3, it appears to be broken.

Prior to 10.6.3, this piece of code would work as expected to get the currently selected track(s):

Appscript.app('iTunes').selection.get()

Now it produces the following error:

RuntimeError: Unknown property, element or command: 'selection'

Edit: Just confirmed that this is also broken in py-appscript, so it's not isolated to rb-appscript.

Which is weird, because the following piece of actual AppleScript still works:

tell application "iTunes" to get selection

Similar examples such as Appscript.app('Finder').desktop.files.get() still work.

I couldn't find any information that would explain if or why this was changed or what I could do to update my script. I'm guessing it has something to do with Mountain Lion changes.

Robert Speicher
  • 15,382
  • 6
  • 40
  • 45
  • This same change also breaks remote scripting with both AppleScript and ScriptingBridge, which Apple is more likely to care about than py-appscript. I'd strongly suggest everyone affected go to http://bugreport.apple.com and file your own bug as a dup of my http://openradar.appspot.com/radar?id=1788405; if they get enough reports it may make a difference. – abarnert Jun 28 '12 at 03:31

3 Answers3

4

Looks like iTunes 10.6.3 was release with the sandboxing that is coming with Mountain Lion. Here is an article talking about it (read the comments, too) http://www.leancrew.com/all-this/2012/06/the-first-nail-in-the-coffin-of-python-appscript/

Probably will start happening much more (if not with everything) as of Mountain Lion

Nate Thelen
  • 58
  • 3
  • +1. But I don't think Mountain Lion is relevant here. The problem is that iTunes is ancient legacy code, which is being slowly modernized by people who don't want to make radical changes to the internals. This led to them partially breaking album art in 10.2, drag&drop in 10.4, and scripting in 10.6.3, but none of that has anything to do with OS X releases (except indirectly, in that Apple could never drop QuickDraw/PICT, QuickTime, 32-bit, etc. while iTunes was still dependent on them). – abarnert Jun 28 '12 at 03:28
2

I have provided a fix for this issue here:

https://github.com/mattneub/appscript/tree/master/rb-appscript

matt
  • 515,959
  • 87
  • 875
  • 1,141
  • Looks great, I'll have to try it; I updated my original script to just make direct calls to `osascript`. – Robert Speicher Jul 24 '12 at 01:43
  • It's working great so far for iTunes, and I'm actively tweaking day by day. However, if there are problems with the way I'm constructing the dictionary, please let me know (ideally you should fork, fix, and enter a pull request). This is definitely a work in progress; the original developer has let go of this ball, so it's up to us all to pick it up and keep it moving. – matt Jul 24 '12 at 16:40
1

Yeah, they definitely broke it. You COULD use rb-appscript with the System Events application to conditionally check the children of various UI elements to see if the 'selected' attribute is true.... e.g.:

i = 0
row_exists = true
selected_row = nil
while row_exists && !selected_row
    i += 1
    row_exists = app("System Events").application_processes["iTunes"].windows["iTunes"].scroll_areas[3].outlines[1].rows[i].exists
    if row_exists 
        if (app("System Events").application_processes["iTunes"].windows["iTunes"].scroll_areas[3].outlines[1].rows[i].attributes["AXSelected"].value.get == true)
            selected_row = app("System Events").application_processes["iTunes"].windows["iTunes"].scroll_areas[3].outlines[1].rows[i]
        end
    end 
end

You could then pull out required information from the children of the selected row. This is would be a pretty annoying way to go about this, though.

lottscarson
  • 578
  • 5
  • 14