Theocacao: The Sleeper Hit Feature in Leopard

Davide — Dec 13, 06 2664

This is lovely news.
I have downloaded RubyOSA and I must say I feel much more confortable scripting with Ruby than with Applescript. Accessing cocoa 'officialy' will make the ruby-scripting experience even greater.

Juan — Dec 13, 06 2665

Holy cow! This is going to attract a whole bunch of developers to OS X.

Dale — Dec 13, 06 2666

I wrote about the Scripting Bridge in my blog. My concern is that it will be limited like NSAppleScript has always been, or more recently like the minimally implemented QTKit, iChat Instant Message Framework, etc.

The article's description is just too light on basic detail to determine if it's worth getting excited about the Scripting Bridge. For example, is the Scripting Bridge two way? I assume you can send data to another app, but the article doesn't say this. Can the Scripting Bridge hand data to another app, let this app transform it, and return it to the original app? How do you work out what code to write? Do you have to write an AppleScript to understand each app's Scripting Dictionary and then translate that into Cocoa?

Don't get me wrong. The Scripting Bridge seems great. And I don't expect to have Leopard's developer documentation released to the public. But it would be good if Apple gave us just enough info to know Leopard's technologies will be useful and not another limited framework.

Scott — Dec 13, 06 2667

This is a fantastic feature. I currently have to write applications using a mix of Cocoa and Applescript Studio in order to be able to use scriptable interfaces and real datatypes. It works but it's pretty clunky.

Being able to simply toll-free bridge to a scriptable application is a huge deal. Especially if they still allow bridging between records and NSDictionaries. This'll really simplify a load of my current utility Applescript Studio stuff.

Yeah!

Scott Stevenson — Dec 13, 06 2668

How do you work out what code to write?

I'm not sure what you mean by this, but I hardly ever use AppleScript so maybe I'm missing something obvious. I always assumed you use Script Editor's "Open Dictionary..." command to understand how to communicate with the application.

Note the key phrase is this:

Scripting Bridge allows you to automatically build "glue" code

Daniel Jalkut — Dec 13, 06 2669

I suspect what Scott suggests is true, that it's just a syntactic shorthand for interacting with any of the published keyed values or commands of a given scriptable application.

So, essentially Apple is providing a proxy object ("iTunes" in the cited example) that probably implements the "valueForKey:" etc methods and creates and compiles an AppleScript to achieve the desired property set, get, or command invocation. Plus, since Apple's in charge, they can tweak for performance and everybody wins.

Pretty cool, if simple, idea.

Clint — Dec 13, 06 2670

I started learning objective-c and then on to cocoa earlier this year. I really like working with objective-c, but i know having another skill to work with would be a great asset (such as python or ruby). I'm wondering what performance penalties, if any, would your app incur for using one or the other as opposed to objective-c?

Jim — Dec 13, 06 2672

I'm wondering what performance penalties, if any, would your app incur for using one or the other as opposed to objective-c?

With a game move search algorithm I did recently, I found that my Obj-C was 30x-40x faster than my Ruby version. YMMV, of course, depending on the nature of the code. For that particular computationally intensive situation, Obj-C was necessary.

For many ordinary apps, I have found Ruby to be plenty fast. Python, in my informal tests, is a bit faster than Ruby -- anywhere from 10% to 40%.

Ruby, however, is simply a joy to use. I'd use it all the time if I could. Once YARV (the on-the-fly compiler in development) is added to the Ruby distribution, Ruby should double, or more, in speed.

Scott — Dec 13, 06 2674

Daniel,

I suspect that what Apple have come up with is an extended framework based on the NSApplescript class. This existing class allows you to load, compile and execute Applescript from within a Cocoa application. However, it's not much fun to use if you want to do anything relatively granular (like get the name of the current iTunes track).

By using a proxy object (as you suggest) with some kind of KVC error checking based on the calling dictionary, I guess you get close to what they're s'pposedly offering.

The fun will start here tho' when working with those, uh, slightly more obtuse Applescriptable applications. There are plenty of Applescript dictionaries out there that baffle even experienced script coders. How that'll all work when you're one level removed behind a toll-free bridge could be entertaining...

mmalc — Dec 13, 06 2675

Laurent Sansonetti gave an overview of some of the new features at RubyConf 2006, reported here[/url/.

Chuck — Dec 13, 06 2677

My suspicion is that the Scripting Bridge isn't a way of hiding AppleScript, but a direct bridge between Objective-C and the Open Scripting Architecture. If I'm right, this makes Objective-C basically a peer to AppleScript rather than a client.

Steven Canfield — Dec 13, 06 2679

The Scripting Bridge analyzes the Applescript dictionary for an app and then generates a header file telling you what the appropriate calls are, since they are app specific. It also sends raw AppleEvents, not compiled AppleScript or interpreted AppleScript. Also, a little bird told me the performance is pretty sweet.

Dale — Dec 13, 06 2680

The Scripting Bridge analyzes the Applescript dictionary for an app and then generates a header file telling you what the appropriate calls are

That's good news. So we don't have to manually do this process ourselves. I was worried we'd have to read the app's dictionary, write an AppleScript to test it (every app's dictionary is different), and then transpose that to the equivalent Cocoa code. Very cool.

Rob — Dec 13, 06 2681

NICE !!!

Chris Ryland — Dec 13, 06 2683

We're not supposed to talk about the scripting bridge details until Leopard is publicly available, but, yes, it's not just a simple hack. It's a "deep, indulgent" scheme.

And, even better, the scuttlebutt (not heard from Apple, so I'm not breaking NDA ;-) is that the Python (and maybe Ruby?) bridge will use Objective-C object management (GC, etc.), so the integration will be great there as well.

Chuck — Dec 13, 06 2684

The Python and Ruby bridges mentioned are surely PyObjC and RubyCocoa, respectively.

Ryan Brown — Dec 15, 06 2707

As far as the Python/Ruby bridge support, they are just endorsing them and improving them. I would be very surprised if any work has been done to integrate the Obj-C GC, as in both cases the Python/Ruby GC is already handling retain counts/autorelease pools/etc for you (the result is you rarely have to worry about mem. management). There is a developer (Laurent Sansonetti, as mentioned in a previous comment) at Apple who has very actively working on RubyCocoa as of late. He has a branch in SVN (apple-unstable) if you want to check it out; the last commit was 2 hours ago :).

Chuck — Dec 15, 06 2708

As of the new release a couple of days ago, RubyCocoa seems to have solved all the issues I had with it (NSView spamming stderr and reference-passing methods not working at all, mainly). Ruby is such a lovely language, it'll be nice to be able to write full-fledged apps with it. It'll be even nicer when YARV comes of age and you can write closed-source apps in it!

Chris Ryland — Dec 17, 06 2737

What I heard is that the PyObjC bridge will in fact use Objective-C object management, which *is* a big deal.

Free papers — Dec 29, 09 7051

Thanks for great materials.

Comments Feed

The Sleeper Hit Feature in Leopard