[Pythonmac-SIG] Re: Re: appscript and XXXX - what is my app instance returning?

has hengist.podd at virgin.net
Fri Apr 1 16:23:02 CEST 2005


'me' wrote:

>>tell application "QuarkXPress"
>>	tell document 1
>>		set pw to page width as real

pw = app('QuarkXPress').documents[1].page_width.get(astype=k.Float)

>But I haven't a clue where to find Quark's coercion method,

You pass the type you want the result returned as as an optional 
argument to the command. It's the same for any app, e.g.:

from appscript import *
print app('Finder').home.items.get(astype=k.alias_list) # return a 
list of Carbon.File.Aliases

Of course, working out what coercions an application implements can 
be a barrel of laughs as it's one of those items that's often not 
documented by the developer.


>or the keyword for number.

AE type constants are in Carbon/AppleEvents.py. Appscript scrapes the 
constant names and lops off the 'type' so that e.g. typeChar becomes 
k.Char, typeFloat becomes k.Float, etc. A better system is definitely 
needed, but I haven't figured one out yet.


>Any other suggestions for converting this AppleScript coercion into python?
>     tell application "QuarkXpress"
>         tell document 1
>              set pw to (page width as number)
>
>pw.get(astype=k.Char)  ## it doesn't like 'astype' or 'k.Char'

The 'astype' argument should work ok. The problem is figuring out 
what value to supply; you'll get a coercion error otherwise. Try 
k.Float (what AS calls 'real').


>pw.get(type=appscript.k.inch_units)
>Unfortunately, using one of Quark's classes simply returns
>another <_AE.AEDesc object>

The 'type' keyword argument isn't recognised, so is simply ignored. 
(I should really go back to raising an error on unknown argument 
names.)


>The trick of passing a coercion was a complete surprise.

It's what AS does, except AS obfuscates it to look like it's the 
language doing the coercion, not the application. AS is master of 
leaky abstractions.


>That idea isn't really obvious from the very nice documentation for appscript.

That's because I somehow forgot to document it. Apologies; I've added 
it to my TO DO list.


>I am still hoping to spawn a more fruitful discussion of how to 
>explore an app's interface using appscript.

What do you need to know?

The built-in help() system is good for interactive exploration. Of 
course, since it depends on the application's terminology resource it 
can't show you any information not already supplied there; all it 
does is present what is available in a more helpful fashion. The 
appscript documentation still lacks a section on the basic concepts 
and principles behind application scripting which is a problem if you 
don't already know what you're looking at; obviously this will be 
addressed at some point.


>But if we're complaining about having to be pre-cognizant of the 
>most minute detail
>for an App's implementation of AppleScript before being able to do 
>anything with it;
>I'd like to point out that being omniscient is a standard 
>requirement for writing IN AppleScript.

Yep. Appscript is NOT a magic fix for the problems caused by 
individual applications' weird or broken scripting implementations 
and painfully inadequate documentation; the only solution for that is 
for individual users to petition those applications' developers to 
fix these problems. File bug reports, file feature requests, have all 
your fellow users get onto them too.

The one thing appscript does give you is a decent language to write 
your scripts in. The AppleScript language, while it has some nice 
features and [largely unrealised] ideas, is mostly a piece of crud: 
slow, buggy, woefully short on the sorts of basic functionality you'd 
expect from any half-decent scripting language, and virtually zero 
library support. (Not the fault of the AS developers; blame the 
clueless  suits in Apple management for suddenly choking off its life 
support two minutes after it was born and neglecting it ever since.)


>To do the most simple thing, you must bang your head against the 
>wall until you hit upon the secret. Either by chance or by reading 
>other people's discoveries. You're never, ever privy to the source. 
>Don't even try to ask.

The first really useful thing to learn in AppleScript is how to 
distinguish application-related problems from language-related 
problems. At least with appscript you only have the 
application-related problems to deal with (well, once it's finished, 
anyway; for now there's still some appscript-related issues to knock 
out, which is why threads like this are always very helpful for me 
too). And once you know a problem is application related, you'll know 
exactly whose balls to go bust until it gets fixed. :) No doubt 
starting with lots of very insistent requests for radically improved 
documentation.


>I am honestly amazed appscript works at all.

I'm not. The underlying technology - Apple events - is really quite 
sound, if not quite of the comfort levels we're used to seeing in 
these days of XML-RPC, SOAP, etc. (Remember, OS 7 was designed to run 
on 30MHz machines with a couple MB of RAM.) Probably the biggest 
problem is that the original APIs for resolving Apple events and 
object specifiers are pretty hairy, much harder to master than the 
equivalent APIs for assembing GUI interfaces, so designing and 
implementing scripting interfaces was really tough for application 
developers to do well. Plus you've got good old early-90s Apple 
slinging all this wonderful powerful complex technology out the door 
and then not bothering to explain to anyone how to actually use it.

Cocoa Scripting was created to address the former problem (though CS 
still has lots of problems of its own), and Apple are ever-so-slowly 
starting to move on the latter (but still have a very long way to 
go). And hopefully application developers will start providing better 
documentation and implementations, especially if/when appscript and 
its ilk start drawing in sizeable numbers of tech-savvy and very 
demanding new users for this technology, cos there's nothing like a 
big vocal userbase banging at the door to motivate developers to do 
better. ;)

Cheers,

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


More information about the Pythonmac-SIG mailing list