On Apr 1, 2009, at 8:15 PM, Ammar Ibrahim wrote:
I'm afraid I'm new and don't quite understand, do you recommend I
use appscript?
I'm biased, of course, but yeah, it's probably the best choice. It's
more powerful and reliable than Scripting Bridge, can be used in
background threads so won't block your GUI on lengthy operations, and
avoids the extra complexity of using a sub-process if you need to pass
non-trivial data.
If so, what's the difference between the following methods:
1- NSAppleScript
Runs AppleScript code within your process.
Pros:
- Nothing speaks Apple events better than AppleScript.
Cons:
- It can only be used on your main thread, so will block your GUI on
lengthy operations.
- While AppleScript itself is very fast at sending events, if you have
to invoke it repeatedly then you will pay a performance penalty due to
the overheads of calling into it.
- If you have to pass complex data between ObjC and AppleScript,
you'll probably spend as much time packing and unpacking that than if
you just called AESendMessage directly with it, unless you use
something like appscript's AEMCodecs class to do that for you.
Notes:
- Generally recommended only for situations where you need to run user-
supplied scripts.
2- Cocoa Scripting Bridge
Sends Apple events directly from Objective-C.
Pros:
- Included in Mac OS X 10.5 and later, which is convenient.
Cons:
- Less capable than AppleScript due to the way its API is designed.
- More prone to application compatibility problems for the same reason.
- Obfuscated API doesn't follow good Cocoa design practices (e.g.
SBElementArray claims to be descended from NSArray, but does not
behave as one).
Notes:
- SB tries to disguise Apple events - which are basically RPC plus
first-class queries - to make them look like object-oriented Cocoa.
This makes it look more familiar - and therefore more attractive - to
existing ObjC/Cocoa developers.
However, there is significant impedance mismatch between the two
systems, so this resemblance is only skin-deep. While SB tries to hide
these differences from the user beneath a thick abstraction layer,
they tend to leak out whenever a target application does not behave
exactly according to SB's in-built assumptions.
Thus commands that work perfectly in AppleScript may fail when
translated to SB, and as SB's internal magic is not publicly
documented, it is considerably harder to troubleshoot the problem and
develop workarounds.
3- AppScript
Sends Apple events directly from Objective-C. (Python and Ruby
versions are also available, and a MacRuby version is under
development.)
Pros:
- Mature design has been heavily field-tested and refined over the
last five years, so application compatibility is very nearly on par
with AppleScript and functionality is equal or better (e.g. thread
support).
- Open-source MIT licensed.
Cons:
- Third-party solution, so you will have to build and include it in
your application bundle yourself.
- Does not hand-hold you or try to make Apple event IPC appear any
less difficult or confusing than it actually is. (Whether this is
really a con, or just refreshing honestly, is a decision left to the
user.)
- Not quite as polished as the Python and Ruby versions, so you may
encounter the odd implementation bug, e.g. I've had a report of
problems in 64-bit processes.
- Single developer - that'd be me - currently up to the neck in work,
so development and support of unpaid projects such as appscript isn't
as active as I'd like (although I wouldn't say it was any worse than
SB support).
Notes:
- Deliberately mimics AppleScript's own behaviours as much as possible
in order to avoid application compatibility problems (i.e. "quirk-for-
quirk compatibility"), so feels quite unlike normal Cocoa APIs. Still
occasionally runs into compatibility problems, but the design is
sufficiently open and flexible that workarounds are usually
straightforward.
- Some knowledge of AppleScript is recommended. (Actually, I would
strongly recommend some knowledge of AppleScript regardless of what
platform you use - you will need it in order to understand existing
example scripts, get help from applescript-users, etc.)
- Make sure you get the ASDictionary and ASTranslate dev tools too.
4- Command line invocation of osascript
Runs AppleScript code within a subprocess.
Pros:
- This avoids the threading problems of calling AppleScript in-process.
Cons:
- It's a traditional command line tool, so you are very limited in
what you can pass in and out - i.e. UTF8-encoded data.
...
Other options to be aware of:
- OSAKit -- more capable, though undocumented, alternative to
NSAppleScript
- Carbon OSA -- more capable than OSAKit, but gnarly Classic-style C
APIs
- AEBuild* functions -- lower level API that constructs Apple events
via printf-style format strings
- Carbon Apple Event Manager -- another Classic-style C API; what
AppleScript, SB, appscript and the rest all build on; low-level and
very verbose for non-trivial tasks
- AEVTBuilder -- third-party ObjC equivalent to AEBuild* functions
- Script Editor applet -- another option for out-of-process execution,
with the advantage over osascript that you can pass complex data via
Apple events (you'll still need some way to send those events on the
client side, so its usefulness is debatable, but I mention it for
completeness). Save your AppleScript as a stay-open application bundle
and add a LSUIElement entry to its Info.plist so that it doesn't
appear in the Dock when running.
HTH
has
--
Control AppleScriptable applications from Python, Ruby and ObjC:
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 arch...@mail-archive.com
