[Pythonmac-SIG] Applescript

[Bob Ippolito]

On Jan 7, 2004, at 6:05 PM, Jack Jansen wrote:

>
> On 7-jan-04, at 17:26, has 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]. I posted a message to the MACSCRPT list in the last  
>> couple of days where I've talked about this issue; I do recommend you  
>> check it out. Here's the archives; look for the 'Perl (and Python)'  
>> thread:
>>
>> <http://listserv.dartmouth.edu/scripts/wa.exe? 
>> A0=macscrpt&D=1&H=0&O=D&T=1>
>>
> 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.

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.

> 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.

> 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.
>
> 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.   
AppleScript uses it, and it's the only good way for humans to use Apple  
Events.  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.  In any  
case, dictionaries/terminologies are not part of the RPC mechanism  
(other than the fact that some applications are nice enough to send you  
a terminology via AppleEvents).  I'm pretty sure that compiled  
AppleScript doesn't have any references to the original terminology  
entries, it's all four character codes.  There is no API to do anything  
with identifiers from terminologies (other than to ask an OSA language  
to compile code).

> 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. OSA is  
> used by Apple sometimes to denote this whole stack of layers,  
> sometimes to denote only this level (the topmost one). The OSA API  
> seems to refer only to the topmost layer. This is the API used by host  
> applications, and it should in principle allow an application to be  
> scripting-language-agnostic: if you are a server for the AppleEvents  
> level and a client to the OSA API level users can use any scripting  
> language to script your application. And of course you can also be  
> only a server (most scriptable applications) or client (MacPython  
> 2.3).

There's three things:
	(1) OSA language (e.g. AppleScript)
	(2) Application that responds to more than the very basic AppleEvents  
(e.g. Finder)
	(3) Application that sends AppleEvents to other applications (e.g.  
MacPython via AppScripting/aeve/gensuitemodule)

You can actually do (2) from MacPython.. I don't know if the Carbon  
wrappers have enough chops to handle it (I'd imagine they do).. but  
*definitely* via PyObjC you have access to enough juice to make a  
scriptable application (on 10.2 or later).

-bob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2357 bytes
Desc: not available
Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040107/9e5e3bd4/smime.bin