• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: other languages in place of AppleScript (was: Re: on neophytes vs perfectionists)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: other languages in place of AppleScript (was: Re: on neophytes vs perfectionists)


  • Subject: Re: other languages in place of AppleScript (was: Re: on neophytes vs perfectionists)
  • From: has <email@hidden>
  • Date: Fri, 19 Dec 2008 23:31:34 +0000

Doug McNutt wrote:

AppleScript is pretty much the only way to access capabilities of GUI
applications written for Macintosh.

Whuuu? High-level Apple event bridges I can think of straight off the top of my head (apologies if I've missed a few):


< koff > Frontier
< koff > Mac::Glue
< koff > Gensuitemodule
< koff > JavaScriptOSA
< koff > OSAPython
< koff > aeve
< koff > appscript
< koff > RubyOSA
< koff-hak > Scripting Bridge

Okay, most of those are either defective and/or dead to one degree or another, but there are still a couple that can be considered genuine alternatives to AppleScript for controlling scriptable applications: Frontier, which predates even AppleScript and was - by all accounts - very good in its day [1], and appscript, which is the next best Apple event bridge you can get after AppleScript itself.


Those "other" scripting languages mostly have a way to get to
AppleScript for the purpose of getting something done that normally
requires human action. If there isn't a specialized interface to
AppleEvents in the language

OK, now I'm confused. When you say "AppleScript", are you talking about the AppleScript language - which *can* be replaced by other languages for application scripting? Or are you using it as a synonym for Mac application scripting/Apple events in general (which will make the discussion really confusing)?



What's hard is creating an AppleEvent and sending it to an
application without the help of AppleScript.

Again, see the above list. None of these bridges rely on the AppleScript language in any way, and the best of them are just as fluent as AppleScript in speaking Apple events. There's no need to use the low-level Apple Event Manager APIs directly unless you're working in a language that doesn't provide a high-level bridge (e.g. C, C++) or are a giant masochist.



There the problem is
extracting the needed command codes from the application. Script
Editor's dictionary processing is pretty much all you get though
there have been some conversions of aevt resources to the likes of
HTML around.

You don't need the raw codes unless you're using the Apple Event Manager API, or the application you're controlling either doesn't have a dictionary or its dictionary contains defects that require you to use raw codes instead of keywords in places (which can be the case in AppleScript too).


As for general documentation tools, ASDictionary exports application dictionaries as HTML in both AppleScript and appscript formats, equivalent to what you get in SE's standard dictionary viewer. Appscript even includes a built-in help() method that can display class and command definitions, inheritance and containment graphs, application objects' current state, etc. - the sorts of features that AppleScript users only get access to if they purchase Script Debugger. You can even use ASTranslate to convert AppleScript commands directly to their appscript equivalents.


The hard parts of scripting applications from other languages are 1. understanding the principles by which Apple event IPC and the Apple Event Object Model operate, and 2. learning how each application implements these technologies in practice. Which are exactly the same challenges faced when scripting applications from AppleScript.



Regards,

has

[1] For those not familiar with Frontier, Matt Neuburg wrote a book on it some years back which includes a chapter on application scripting. There's a free online version on his website: http://www.tidbits.com/matt/defaultfrontier.html

--
Control AppleScriptable applications from Python, Ruby and ObjC:
http://appscript.sourceforge.net

_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users

This email sent to email@hidden
  • Follow-Ups:
    • Re: other languages in place of AppleScript (was: Re: on neophytes vs perfectionists)
      • From: Shane Stanley <email@hidden>
  • Prev by Date: Re: Tell Blocks Considered Harmful
  • Next by Date: Re: on the lack of documentation (was: Re: on neophytes vs perfectionists)
  • Previous by thread: Re: on neophytes vs perfectionists (was Re: Tell Blocks Considered Harmful)
  • Next by thread: Re: other languages in place of AppleScript (was: Re: on neophytes vs perfectionists)
  • Index(es):
    • Date
    • Thread