Re: Scripting Bridge question
Re: Scripting Bridge question
- Subject: Re: Scripting Bridge question
- From: email@hidden
- Date: Thu, 15 Nov 2007 23:06:08 +0100
Thanks for the detailed explanation. Very enlightening. [[artwork
data] description] tells me I got an NSImage, just as you:
NSImage 0x1f5510 Size={944, 921} Reps=(
NSPICTImageRep 0x109950 Size={944, 921}
ColorSpace=NSCalibratedRGBColorSpace BPS=0 Pixels=944x921 Alpha=NO
)
Yet I can't use this as-is in an NSImageView for some reason. Maybe I
need to pull the raw data out of the NSPictImageRep first, and create
an NSImage out of that? But then, how do I do that? I searched the
archives and it seems awfully complicated. Also, my main concern is
speed. Would such a conversion be slower than using the NSAppleScript
approach? Any way I can get the AEDesc's raw data directly from the
iTunesArtwork property?
On Nov 15, 2007 9:46 PM, has <email@hidden> wrote:
> email@hidden wrote:
>
> > What bugs me is that
> > both the NSAppleScript and the ScriptingBridge approach are supposed
> > to return the exact same results, yet
>
> Not true: -[NSAppleScript executeAndReturnError:] always returns an
> NSAppleEventDescriptor which you are responsible for unpacking
> yourself. The type of value returned by Scripting Bridge depends on
> various factors which I can't be bothered listing, but in this case it
> should return an NSImage instance as SB knows how to map between
> AEDescs of typePict, typeTIFF, etc. and the Cocoa equivalent.
>
> As an aside: don't assume that operations that work in AppleScript are
> always guaranteed to work in Scripting Bridge, or at least not without
> kludgy workarounds. It's a long, long story which I hope to go into
> when I've a bit more time on my hands, but short version is that SB
> has its own rather strong opinions about how Apple event IPC _should_
> work which are not necessarily related to how it actually _does_ work
> in the real world. That isn't the issue here, but if you Google for
> "Scripting Bridge" hits made in the last month, you'll find several
> discussions of compatibility problems, including some relating to
> other aspects of iTunes scripting.
>
>
> > [[[[NSAppleScript alloc] initWithSource:@"tell application \"iTunes\"
> > to return data of artwork 1 of current track"]
> > executeAndReturnError:nil] data]
> >
> > works, but [artwork data] doesn't... Oh well, I'll keep trying.
>
> Note that these two -data methods are not the same.
>
> The first, -[NSAppleEventDescriptor data], returns an NSData instance
> containing a copy of the AEDesc's raw data; your original
> NSAppleScript example then shoves this data into an NSImage object
> that you can use in the rest of your code.
>
> The second, -[itunesArtwork data], returns an NSImage instance which
> you should be able to use as-is.
>
> e.g. The following works here for a track that I dropped a .gif file
> on just to test it:
>
> #!/usr/bin/python
>
> from ScriptingBridge import *
>
> itunes =
> SBApplication.alloc().initWithBundleIdentifier_('com.apple.itunes')
>
> print itunes.currentTrack().artworks()[0].data()
>
> Result:
>
> NSImage 0x2135b70 Size={324, 325} Reps=(
> NSPICTImageRep 0x2135e70 Size={324, 325}
> ColorSpace=NSCalibratedRGBColorSpace BPS=0 Pixels=324x325 Alpha=NO
> )
>
> If no track is active, or if the active track doesn't have any artwork
> attached, you'll get an object not found error (-1728). If that's not
> the cause of your problem, I suppose it's also possible that there
> could be a bug in the AE-Cocoa picture type mappings. You'd need to
> provide more info on the reported error (and, if it's an SB bug, a
> copy of the problem image) in order to say for sure.
>
>
> has
> --
> http://appscript.sourceforge.net
> http://rb-appscript.rubyforge.org
>
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> 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:
>
> This email sent to email@hidden
>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden