You’re looking at a draft of a chapter from a work in progress, tentatively titled Scripting Mac Applications With Ruby: An AppleScript Alternative, by Matt Neuburg.
Covers rb-appscript 0.6.1. Last revised Jun 23, 2012. All content ©2012 by the author, all rights reserved.
Appendix A: Where to Go From Here
This appendix mentions some resources for further study and additional options for scripting Macintosh applications.
This book has not attempted to reproduce or substitute for rb-appscript’s own documentation. At some point, you’re probably going to want to read that documentation. Furthermore, rb-appscript is open source and you can examine its code; you might eventually like to do that as well.
For one thing, rb-appscript includes AEM, a library for working with Apple events at a somewhat lower level than Appscript. This book has made some use of AEM without explanation. To understand what’s going on in that code, you’d need to read the documentation on AEM and look at the rb-appscript code.
Hamish Sanderson has developed the Appscript libraries in a language-neutral fashion, so that they can be translated to work in different languages.
In fact, Appscript didn’t start out as a Ruby library; it started out as a Python library, and the Python version, py-appscript, is very similar to rb-appscript. So you can use Appscript from within Python if you’re so inclined.
There is also an Objective-C port, so that Appscript can be used from within Cocoa applications. Unlike the Ruby and Python versions, the Objective-C Appscript methods must exist at compile time, so the Objective-C version operates by generating “glue code” beforehand.
And finally, although prediction about the future is always risky (I usually stick to prediction about the past, myself), when MacRuby finally emerges into the light of day, there might be an Appscript library for that too.
AppleScript has certain system-level privileges that Appscript does not share. AppleScript is an OSA language (Open Scripting Architecture), which means that applications can call into it through various mechanisms. AppleScript is recordable; an application can broadcast the AppleScript equivalent of user actions, so that the user can build a script by enacting its desired effects. AppleScript is attachable; an application can permit a user to dictate all or part of a menu action, for instance, as a compiled script. AppleScript is callable; an application can run a specific handler in a compiled script, as is done with folder actions. You won’t be using Appscript in any of those ways.
The chief competition to Appscript comes, as I mentioned in the Introduction, from Apple itself. For Apple’s Scripting Bridge, and for evidence of Apple’s concern to provide alternatives to AppleScript, see for example http://developer.apple.com/documentation/Cocoa/Conceptual/RubyPythonCocoa/Introduction/Introduction.html and http://developer.apple.com/releasenotes/scriptingautomation/RN-ScriptingBridge/. RubyOSA, in particular, is an attempt to do almost exactly the same thing that rb-appscript does (see http://developer.apple.com/documentation/Cocoa/Conceptual/RubyPythonCocoa/Articles/Using%20RubyOSA.html). I happen to think that rb-appscript is a better implementation.
You’re looking at a draft of a chapter from a work in progress, tentatively titled Scripting Mac Applications With Ruby: An AppleScript Alternative, by Matt Neuburg.
Covers rb-appscript 0.6.1. Last revised Jun 23, 2012. All content ©2012 by the author, all rights reserved.
This book took time and effort to write, and no traditional publisher would accept it. If it has been useful to you, please consider a small donation to my PayPal account (matt at tidbits dot com). Thanks!