[Pythonmac-SIG] Applescript

[has]

Bob wrote:

>>>BTW, one other thing: it'll save you a LOT of mental anguish if 
>>>you realise from the start that application objects are referred 
>>>to using basic relational queries [4]. Most folk don't realise 
>>>this, especially since AppleScript uses syntax that looks much 
>>>like standard OO [5].
>>>
>>This paragraph leads me to believe that you're the first person (or 
>>one of the first people) I've met in my 8 year quest to understand 
>>the AppleScript machinery who actually understands what is going 
>>on. Unfortunately, however, I'm not sure I understand what you're 
>>saying, either in this paragraph or in the discussion on the 
>>scripting mailing list.

I shouldn't be surprised - I often can't understand me either. The 
gold-to-bullsh*t ratio is often rather poor to begin with, but I 
generally just keep on trying till I get it more or less right. <g>


>He certainly knows a whole lot more than I do about AppleEvents.. 
>I've had less than a year of experience with them and don't have 
>significant AppleScript experience.

Depends what you mean. I expect you can find your way around the 
Carbon APIs and all the other low-level stuff a LOT easier than I 
can, given that I have no C or other low-level programming 
experience. What I do have <blush> a very good grasp of the 
high-level principles by which AppleEvent-based interapplication 
control operates - or ought to operate anyway (given the amount of 
applications, documentation, APIs, etc. that seem to get it wrong in 
one respect or another).

This is due to an almost unbelievable amount of time spent banging 
away at the AppleScript language and application scripting until I 
finally understood it close to perfectly as makes no difference. In 
fact, AppleScript is very much my alma-mater; I didn't have any 
coding experience (other than a little 80's BASIC from childhood) 
before then, and like most folk I got into it because I was lazy and 
wanted to automate a bunch of stuff at work, and because it had that 
"friendly English-like syntax" that tends to draw in so many naive 
and unsuspecting newcomers. (And I'll leave you to think up your own 
florid metaphors for this seduction of the innocent; of seedy men 
driving slowly past schoolyards in unmarked vans, etc.;) The only 
difference being that most folk get 'just good enough' at it to do 
what they want, whereas I just kept going - I'm stupid/persistent 
like that. With a lot of red face moments from heading down every 
wrong turn till finally getting it right, of course.

Needless to say, I'm still very peeved that it's taken me so long to 
get to where I am now, and I've every sympathy for others who brave 
the same path. And AppScripting is now my second attempt to do 
something concrete about it, given that Apple seem so frustratingly 
content to let the many problems with IAC, AppleScript and - most 
especially - their documentation of it just amble along year on year 
when what's really needed is some massive action (and maybe a ton or 
two of TNT too).

(Short version: have some patience with the crazy guy bouncing 
annoyingly in the corner - he's often wrong, but when he gets on the 
right track he can be very right indeed.;)



>>It would help me immensely if you could help me (and probably 
>>numerous others) get things straight....
>>
>>Here's what I understand so far, please tell me what's wrong with 
>>this, and where I miss things.
>>
>>The whole things is a layered set of protocols and APIs. At the 
>>very bottom we have IAC (Inter-Application Communication), which is 
>>basically a low-level API to do message passing, both inter and 
>>intra-machine. Under OS9 you could use this raw, but as far as I 
>>can tell that is no longer true under OSX.
>
>I think you can still use some of these mechanisms, but I don't 
>think anyone ever really did.  From what I remember it's called PPC 
>(Program to Program Communication?  It sure as hell isn't the PPC 
>we're used to hearing) and sits on top of Mach ports in OS X.

You're thinking of MacOS's Process-to-Process Communications Toolbox. 
This is absent in OS X, which uses Mach messaging instead. Like you 
say, hardly anyone ever ventured that far down to the basement in 
practice; certainly for our purposes you really don't need to know 
about anything below the Apple Event Manager and Apple events. So 
this stuff can (and should) be ignored.


>>The next level up is AppleEvents, which is a number of things all entangled:
>>1. An API for doing RPC (remote procedure calls),
>>2. A data encoding format for RPC parameters (similar to what ASN-1 
>>or XDR provides),
>>3. A data model (classes, properties, iterators, tests, etc),
>>4. An API for encoding and decoding the format of (2) and (3).
>>All in all this level provides similar services to what COM or 
>>Corba provides.

Uh-huh. The Apple Event Manager provides the API for your #1 and #4. 
(No point asking me about COM and Corba as I'm not familiar with 
those, but will take your word for their being similar.) As for the 
data model stuff, it's very much provided in flat-pack form: while 
AEM has occasionally heard of curious things called "classes" and 
"properties", it's not really all that interested in such 
high-falutin' stuff. All it really cares about is structs, strings, 
and lots and lots of mechanically efficient though deeply 
human-unfriendly four-letter codes that describe the many meanings of 
the various collections of crude parts that pass through it.

It's also worth noting that this layer provided the day-to-day 
interapplication communication services that appeared in System 7, 
which was the first version of MacOS to provide native support for 
cooperative multitasking. The obvious example is of the Finder using 
AEs to communicate with other applications, sending them lists of 
files to open or print, telling them to quit when the system was shut 
down, etc.

I suppose it would be inevitable that some bright spark would at some 
point realise that this mechanism could be harnessed by other types 
of clients... like, oh... say, a high-level scripting language. So 
controlling applications from scripts is more a fringe benefit of AEs 
and AEM - albeit one that turned out to be very valuable to a lot of 
important Apple customers (i.e. the publishing market) - than its 
core raison-d'etre.

...
All of which takes us onto the next topic of interest: the Open 
Scripting Architecture (and associates).

>>Then there's dictionary/terminology level, which is really unclear 
>>to me. In part it is part of the previous level. In part it is a 
>>level by itself: it allows applications to build on the data model 
>>and define which classes, properties, etc. it supports and 
>>communicate that to other applications. In part it is part of the 
>>next level: all sorts of AppleScript words appear in the 
>>dictionaries. Documentation on this level appears to be completely 
>>lacking: getting the terminology resource of application is a black 
>>art (sometimes you can use AppleEvents to get it, sometimes you 
>>have to hunt for an 'aeut' or 'aete' resource, sometimes there's 
>>only an XML file in an unspecified format).
>
>The dictionary/terminology level is just (unvalidated) metadata.

Yes. Although the 'unvalidated' bit may not be entirely true: one 
should reasonably assume that it has at least been checked for 
correctness by its original authors before they stuck it in (ho-ho), 
and I think Cocoa also makes some use of it in performing 
sanity-checking on incoming events that will be handled through the 
Cocoa framework's scripting support facilities.


>AppleScript uses it, and it's the only good way for humans to use 
>Apple Events.

Except if you're the sort of sick puppy who genuinely enjoys dealing 
with vast swathes of utterly cryptic computer-y codes. In which case 
I can probably find you a nice 1980s list of Z80 and 6502 assembler 
codes that'll totally float your boat.;)

For everyone else though, it's a way to translate AE codes into 
something meaningful, as well as being a form of user documentation 
in itself. In addition to providing mappings between the four-letter 
codes used by AEM, the application terminology resource also contains 
information describing how a particular application's scripting 
interface works. (Although this information is far from 
comprehensive, much to the chagrin of many a user left to fill in the 
missing knowledge for themselves through folk wisdom and much trial 
and error.)


>   I'm relatively sure that the XML file only happens for Cocoa 
>applications.  I believe the format is indeed specified somewhere, 
>and I'm also relatively sure that anything that has this kind of XML 
>file is going to respond to the AppleEvent method of fetching it.

The encoding of the terminology resource is irrelevant to clients; 
only application developers need worry their heads about such 
nonsense, and the smart ones will likely use tools to generate it all 
anyway. (In OS7-9 it was binary format; in OS X it's either key-value 
lists or in XML plist format.)

As for clients getting hold of the terminology for a particular app, 
this should be done via the OSA API which provides the necessary 
services. (I'm sure I don't need to lecture anyone on the follies of 
nipping around official APIs and sticking their bits in where they're 
not meant to be. And any accusations of aeve and appscript doing just 
such a thing themselves shall be dismissed as temporary technical 
difficulties; soon to be resolved, etc.;)


>I'm pretty sure that compiled AppleScript doesn't have any 
>references to the original terminology entries, it's all four 
>character codes.

Correct. What a particular OSA client chooses to do with the 
application terminology is up to it. The AppleScript language 
component uses it only to translate between 'plain English' keywords 
and AE codes when compiling and decompiling scripts. While 
applications such as Script Editor, Smile and Script Debugger use it 
to generate user-readable documentation describing an application's 
scriptable interface, just as the application's printed/electronic 
manual typically describes its graphical interface (and/or 
command-line interfaces for folk that like that sort o' thing).



>>Next level up is actual scripting languages. AppleScript is the 
>>main one here, but in principle  this level is open. Frontier is 
>>(or used to be) another scripting language within this 
>>architecture, and we want Python to be usable at this level too.
>>
>>Next level up is the OSA (Open Scripting Architecture) API.

You've got these the wrong way around. OSA provides a component 
mechanism for handling OSA-compatible language components. (The old 
MacOS being very big on component architecture for providing 
hot-swappable software plug-n-play at runtime. Probably the 
best-known of these components being Apple's famous Quicktime.)

Scripting languages can then plug into OSA. Some might employ it just 
for fetching terminology resources from apps, while others will use 
it to elevate themselves to full-blown component-hood. (Even then, 
some may support more OSA-based services than others; aside from the 
core commands such as compile and execute, most are optional.)

BTW, remember that OSA and AEM are two separate things. I tend to 
think of OSA as sitting at a level higher than AEM myself. But while 
OSA is itself a client of AEM, you can, for example, have an OSA 
client that isn't a client of AEM (e.g. Brent Simmon's OSAShell 
language component; the old Script Editor [which didn't associate 
with AEM like the new one does, aside from having to support the 
Required Suite like all good Mac apps, of course]), or an AEM client 
that has nothing to do with OSA (aside from the obvious example of 
direct application-to-application communication, the current release 
of appscript immediately comes to mind).


>>OSA is used by Apple sometimes to denote this whole stack of layers,

True. But considering that Apple uses the name "AppleScript" to cover 
everything from "Programming-for-Beginners" (Basilisk edition), to 
scripts-based interapplication control, to the Ultimate Answer to 
Life, the Universe, and Whatever Else Might Ail You, I shouldn't pay 
too much attention to what Apple declares OSA to be on any particular 
day of the week.;p


>>This is the API used by host applications, and it should in 
>>principle allow an application to be scripting-language-agnostic:

No. All scriptable applications are client-agnostic, knowing nothing 
of the client that's sending them AppleEvents. (Exactly as things 
should be.) Both client and server in this case use AEM: the client 
to construct and dispatch AppleEvents; the server to decode the 
incoming AppleEvents and, in many cases, to assist in performing the 
operations requested by these events as well.

Some applications - aside from Script Editor and co. - do employ both 
AEM and OSA. These are the applications that fall into the Recordable 
and/or Attachable categories. A recordable application is one that 
monitors messages sent from the GUI to the application model and 
converts them into AppleEvents as this happens; spewing these into a 
nearby script that the user can then run themselves every time they 
want to replay their original actions; basically just an elaborate 
system for creating macros. Attachable apps range from applications 
that include a Scripts menu (e.g. Eudora, Tex-Edit Plus) which allows 
users to execute scripts without having to open and execute them in 
the Script Editor (or launch them from the Finder if they're saved as 
applets) to something like Smile, which has an extensive scripting 
interface where every application object can have a script directly 
attached to it (while its core is C/C++[?], a large chunk of the 
Smile app is actually written in AppleScript).



Man, what a doozy. It's now 3 a.m. here, so if you have trouble 
grokking this [rather lengthy] response then rest assured it's at 
least as likely my fault as yours.  ;)

HTH

has
-- 
http://freespace.virgin.net/hamish.sanderson/