Re: Problems with ScriptingBridge and iTunes
Jens Alfke wrote: Moreover, since Obj-C is a dynamic language, it's more important what the class of the object is at runtime, than what type the pointers are defined as at compile time. You can change the type declarations, but it won't affect what actual objects you get back at runtime. This is particularly true when dealing with scriptable applications, given that the type information provided by application dictionaries - which is what sdp uses to generate Scripting Bridge headers - is not always accurate. Most of the information provided by application dictionaries is only there for documentation purposes and is completely ignored by AppleScript. Given that application developers have spent the last decade designing and testing their applications to work with AppleScript, it's not unusual for errors in the documentation-only portions of the application dictionary to slip through. For example, iTunes' 'add' command claims to return a 'track' reference, but it actually returns a list of track references if more than one file is supplied. Another problem is that the dictionary format - particularly the older aete format which is still used by most applications - is a bit limited in its expressiveness, so even a dilligent developer may be unable to describe every last detail of a particular command's parameter and return values. For example, Address Book's dictionary states that a 'person' object's 'last name' property contains a string, and it usually does; however, it can also contain a 'missing value' constant if a person's last name isn't known. This is why objc-appscript simply declares all property, parameter and return types as 'id', on the basis that the user will know more about the types of values that a particular application will accept and return than it does, and perform any necessary type checks themselves. It also provides several convenience methods (-returnType:, - returnList, -returnListOfType:, -returnDescriptor) for ensuring a return value is converted to a specific type (or an error raised), which is handy for dealing with carelessly inconsistent commands such as 'add' (which, if it was better implemented, would _always_ return a list, regardless of how many files are supplied). ... BTW, if all this sounds a bit untidy and less than ideal for users... well, it is. Alas, while the principles behind Apple event IPC are simple enough, the day-to-day practicalities of using it are a bit more complicated due to the great variations in design and quality between individual applications' scripting interfaces. Scripting Bridge, whether by hubris, naïveté or embarrassment, attempts to gloss over the flaws and imperfections of AppleScript's world and pretend that they don't exist. Appscript, OTOH, accepts the current situation on its own terms and merely aims to provides you with a good, solid set of tools for dealing with it. It might not look quite as pretty or 'pure' as SB, but it shouldn't jump up and bite you on the butt when you aren't expecting it either. HTH has -- http://appscript.sourceforge.net ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Problems with ScriptingBridge and iTunes
Thank you for the update on that sample code. I was hoping it would continue to be ignored because I was publicly berated in the #macdev channel for posting it, but oh well. Thanks to Wolf's post up there, I'm not going to continue to learn SB any longer, and I just hope Apple fixes it up. On Mon, Mar 3, 2008 at 12:32 AM, Jens Alfke [EMAIL PROTECTED] wrote: On 2 Mar '08, at 4:54 AM, Steven Degutis wrote: I think it's clear why [currentTrack isKindOfClass:[iTunesFileTrack class]] evaluates to true: in the previous line, you defined it as such, like this: iTunesTrack *currentTrack = [iTunes currentTrack]; So obviously it is an iTunesTrack! No. It could be an instance of a subclass of iTunesTrack, such as (in this case) iTunesFileTrack. (That's true of any object-oriented language.) Try this: iTunesFileTrack *currentTrack = [iTunesFileTrack currentTrack]; That won't even compile. You can't assign an iTunesTrack* to an iTunesFileTrack*. Moreover, since Obj-C is a dynamic language, it's more important what the class of the object is at runtime, than what type the pointers are defined as at compile time. You can change the type declarations, but it won't affect what actual objects you get back at runtime. —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Problems with ScriptingBridge and iTunes
On 3 Mar 2008, at 15:27, Steven Degutis wrote: Thank you for the update on that sample code. I was hoping it would continue to be ignored because I was publicly berated in the #macdev channel for posting it, but oh well. Don't feel too bad: if you're coming from a Cocoa background, application scripting is a very different beast to what you're used to, and Scripting Bridge's deliberately dishonest design is pretty much guaranteed to give you a completely incorrect understanding of how it works if you pay any attention to it. Like I say, the basic principles are actually pretty simple, and most of the confusion here is down to AppleScript's use of OO-like syntactic sugar. While it certainly makes Apple events easier to use, it also encourages unsuspecting newcomers to assume that because it looks OO-ish, it *is* OO. This wouldn't be such a big problem if the AppleScript documentation clearly indicated that the OO-like syntax is purely for ease of use, before explaining the actual RPC+query- oriented mechanics behind it. Unfortunately, the AppleScript documentation heavily [over-]simplifies the technical details, presumably in an attempt to make them easier to understand. This sort of creative fictionalising might be an acceptable compromise to make for the non-technical audience that AppleScript is primarily aimed at, but it's a real pain for professional programmers trying to make sense of AppleScript technology. In the absence of better information, the typical Mac programmer will look at the existing AppleScript syntax and documentation and from that conclude that it since it looks like OO, it must behave like it as well. Again, most of the actual behaviour is close enough to what's anticipated that most folks manage to get by for most of the time, even with a flawed understanding of what's going on. However, it hardly inspires any sort of confidence in the technology when you're less than certain what exactly is going on, and troubleshooting your code whenever something does go wrong is going to be difficult at best. Non-programmers may tolerate this simply because they don't realise when they're being messed around, but professional developers generally have better things to do with their time and don't take kindly to such treatment. Thanks to Wolf's post up there, I'm not going to continue to learn SB any longer, and I just hope Apple fixes it up. While SB isn't so utterly defective as to be unusable, it still isn't close to being an improvement over AppleScript. If you want to control scriptable applications from other languages then appscript remains the best technical choice. Again, my advice would be to read the appscript documentation, William Cook's AppleScript papers, Matt Neuburg's AppleScript book, and spend a bit of time playing around with appscript (the Python and Ruby versions are particularly good for exploring application scripting since they can be used interactively and provide very nice built-in help). You'll still have to deal with the many quirks, bugs and other shortcomings of individual scriptable applications, but at least you don't have to put up with a third-rate language/bridge on top of that. HTH has -- http://appscript.sourceforge.net ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Problems with ScriptingBridge and iTunes
Hannes,
I haven't heard of this ITApplication before, but for your specific
problem, I think it's clear why [currentTrack
isKindOfClass:[iTunesFileTrack class]] evaluates to true: in the
previous line, you defined it as such, like this:
iTunesTrack *currentTrack = [iTunes currentTrack];
So obviously it is an iTunesTrack!
Try this:
iTunesFileTrack *currentTrack = [iTunesFileTrack currentTrack];
NSLog(@%@, [currentTrack location]);
Since iTunesFileTrack is a subclass of iTunesTrack, it should work,
giving you the info you need.
On Sun, Mar 2, 2008 at 6:05 AM, has [EMAIL PROTECTED] wrote:
Hannes Petri wrote:
I want to retrieve the path to the currently played file in iTunes. I
thought scripting bridge would be the perfect tool for this, however
i've run into some problem. I have this code:
iTunesApplication *iTunes = [[SBApplication alloc]
initWithBundleIdentifier:@com.apple.iTunes];
iTunesTrack *currentTrack = [iTunes currentTrack];
if ([currentTrack isKindOfClass:[iTunesFileTrack class]]) {
}
The problem is, that the class of the object returned is _always_
iTunesTrack, and not iTunesFileTrack, as i expect it to be.
Here's how you'd do it using objc-appscript
http://appscript.sourceforge.net/objc-appscript.html
:
// To generate iTunes glue: osaglue -o ITGlue -p IT iTunes
#import Foundation/Foundation.h
#import ITGlue/ITGlue.h
int main (int argc, const char * argv[]) {
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
ITApplication *itunes = [[ITApplication alloc] initWithBundleID:
@com.apple.itunes];
ITReference *track = [itunes currentTrack];
ITConstant *trackClass = [[[track class_] get] send];
if (trackClass == [ITConstant fileTrack]) {
ASAlias *trackFile = [[[track location] get] send];
NSLog(@%@, trackFile);
}
[itunes release];
[pool drain];
return 0;
}
HTH
has
--
http://appscript.sourceforge.net
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/sephknows%40gmail.com
This email sent to [EMAIL PROTECTED]
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: Problems with ScriptingBridge and iTunes
On 2 Mar '08, at 4:54 AM, Steven Degutis wrote: I think it's clear why [currentTrack isKindOfClass:[iTunesFileTrack class]] evaluates to true: in the previous line, you defined it as such, like this: iTunesTrack *currentTrack = [iTunes currentTrack]; So obviously it is an iTunesTrack! No. It could be an instance of a subclass of iTunesTrack, such as (in this case) iTunesFileTrack. (That's true of any object-oriented language.) Try this: iTunesFileTrack *currentTrack = [iTunesFileTrack currentTrack]; That won't even compile. You can't assign an iTunesTrack* to an iTunesFileTrack*. Moreover, since Obj-C is a dynamic language, it's more important what the class of the object is at runtime, than what type the pointers are defined as at compile time. You can change the type declarations, but it won't affect what actual objects you get back at runtime. —Jens smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Problems with ScriptingBridge and iTunes
Hello!
I want to retrieve the path to the currently played file in iTunes. I
thought scripting bridge would be the perfect tool for this, however
i've run into some problem. I have this code:
iTunesApplication *iTunes = [[SBApplication alloc]
initWithBundleIdentifier:@com.apple.iTunes];
iTunesTrack *currentTrack = [iTunes currentTrack];
if ([currentTrack isKindOfClass:[iTunesFileTrack class]]) {
…
}
The problem is, that the class of the object returned is _always_
iTunesTrack, and not iTunesFileTrack, as i expect it to be. If i run
the following applescript code:
tell application iTunes to current track
I get a file track, which makes it possible to fetch the path using
the location attribute. If I, in the ObjC example, try [currentTrack
location], I'm told that it doesn't respond to that selector.
I have made certain that the object is of class iTunesTrack by typing
'po [currentTrack class]' in gdb.
Very thankful for help!
Hannes Petri___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: Problems with ScriptingBridge and iTunes
On Mar 1, 2008, at 7:28 PM, Hannes Petri wrote:
iTunesApplication *iTunes = [[SBApplication alloc]
initWithBundleIdentifier:@com.apple.iTunes];
iTunesTrack *currentTrack = [iTunes currentTrack];
if ([currentTrack isKindOfClass:[iTunesFileTrack class]]) {
…
}
The problem is, that the class of the object returned is _always_
iTunesTrack, and not iTunesFileTrack, as i expect it to be. If i run
the following applescript code:
tell application iTunes to current track
I get a file track, which makes it possible to fetch the path
using the location attribute. If I, in the ObjC example, try
[currentTrack location], I'm told that it doesn't respond to that
selector.
I have made certain that the object is of class iTunesTrack by
typing 'po [currentTrack class]' in gdb.
I ran into the same thing -- Scripting Bridge may play games
isKindOfClass: that bite us. My work-around is to test by class name:
if ([[track className] isEqualToString:@ITunesURLTrack]) { /* ... */ }
| Jonathan 'Wolf' Rentzsch http://rentzsch.com
| Red Shed Software http://redshed.net
| better necessarily means different
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
