Re: No track index in iTunes SB?

FROM : has
DATE : Mon Mar 10 21:30:04 2008

Christopher Nebel wrote:

>> Anyone know how to get the index of the current iTunes track using 
>> Scripting Bridge? With Applescript, it's as simple as "tell iTunes 
>> to return index of current track", but iTunes SB has no such 
>> property (well, there is one, but it only refers to the index of 
>> the current playlist). It seems the iTunesTrack index property is 
>> simply missing...? Or am I missing something?

>
>
> What's missing is the line in iTunes' dictionary that says that 
> tracks have an "index" property in the first place. Scripting Bridge 
> takes the dictionary at its word, and therefore, no -[iTunesTrack 
> index] accessor. Ultimately, it's an iTunes bug.


While it's true that iTunes dictionary is less than 100% accurate in 
its description of its Apple event API, Scripting Bridge deserves its 
share of the blame for ignoring the realities of AppleScript's world.

In this particular case, AppleScript ignores the hierarchical or type 
information given in dictionaries (historically supplied for 
documentation purposes only), so minor mistakes in these areas often 
go unnoticed for years by application developers since they don't 
cause errors in AppleScript. (Though by all means submit bug reports 
on them, as documentation errors are still errors, and best fixed.) 
It's Scripting Bridge that chose to be different here, and use this 
information for runtime purposes as well - even with the knowledge 
that it was less than 100% reliable.

Nor do dictionaries actually have to be in error in order to flummox 
Scripting Bridge this way. Given the nature of the dictionary format 
(particularly the older aete format), there are times when it merely 
isn't practical and/or convenient to provide comprehensive hard-coded 
type information. For example, here's a perfectly legal AppleScript:

   tell application "Finder"
       get name of every item of entire contents of folder "Documents" of 
home
   end
   --> {"Adobe Fonts", "AdobeStockPhotos", "ashopl.pdf", ...}


plus the objc-appscript equivalent, demonstrating that this behaviour 
is entirely repeatable on other platforms:

   #import "FNGlue/FNGlue.h"

   // To create Finder glue: osaglue  -o FNGlue  -p FN  Finder

   int main (int argc, const char * argv[]) {
       NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];

       FNApplication *finder = [[FNApplication alloc] initWithBundleID: 
@"com.apple.finder"];
   
       FNReference *ref = [[[[[[finder home] folders] byName: @"Documents"] 
entireContents] items] name];
   
       NSLog(@"%@", [[ref get] send]);
   
   [finder release];
   [pool drain];
   return 0;
   }

Result:

   2008-03-10 19:29:01.505 FinderTest[17031:10b] (
       "Adobe Fonts",
       AdobeStockPhotos,
       "ashopl.pdf",
       ...
   )

   The Debugger has exited with status 0.


And here's the Scripting Bridge equivalent, having the same tizz as 
before (only at runtime, since I'm using Ruby+RubyCocoa instead of 
ObjC to show it's not just a compile-time problem):

   #!/usr/bin/ruby

   require 'osx/cocoa'
   include OSX
   OSX.require_framework 'ScriptingBridge'

   app = 
SBApplication.applicationWithBundleIdentifier_("com.apple.finder")

   puts 
app
.home
.folders
.objectWithName_
('Documents').entireContents.items.arrayByApplyingSelector_(:name)

   # ERROR: Can't get Objective-C method signature for selector 'items' 
of receiver #<OSX::SBObject:0x229728 class='SBObject' id=0x5662a0> 
(OSX::OCMessageSendException)


Even something like this:

   tell application "Finder" to get (original item of item "somefile 
alias" of home)

is perfectly legal in AppleScript's world, since it's up to the server 
(the target application), not the client, to decide if and how a given 
query should be resolved. But again, don't expect it to work in 
Scripting Bridge.


In other words, while pointing out that iTunes' dictionary has a minor 
bug in it may be technically correct, it completely ignores the much 
larger problem: Scripting Bridge's bone-headed insistence on speaking 
Apple events the way it _thinks_ they should be spoken, rather than 
the way they _actually_are_.


has
--
Control AppleScriptable applications
from Python, Ruby and ObjC:
http://appscript.sourceforge.net