[Pythonmac-SIG] Re: Re: appscript and XXXX - what is my app
hengist.podd at virgin.net
Fri Apr 1 16:23:02 CEST 2005
>>tell application "QuarkXPress"
>> tell document 1
>> set pw to page width as real
pw = app('QuarkXPress').documents.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').
>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
>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
>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
>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
More information about the Pythonmac-SIG