[Pythonmac-SIG] Re: Re: appscript and XXXX - what is my app
instance returning?
Peter Waibel
waibel at opix.de
Fri Apr 1 20:03:37 CEST 2005
Try this:
####################################
#!/usr/bin/pythonw
from appscript import *
qxd = app('QuarkXPress')
# get the page width
pw_hm = qxd.documents[1].page_width.get()
# pw_hm is quarks class horizontal_measurement
# coerce horizontal_measurement to k.Float
pw_float = qxd.coerce(pw_hm,to=k.Float)
print pw_float
###################################
Quark uses a lot of special data types:
agate_units
centimeter_units
cicero_units
inch_units
inch_decimal_units
millimeter_units
pica_units
point_units
base_units
font_units
grid_increment_units
inset_units
leading_units
outset_units
thick_units
trap_units
agates_point
agates_rectangle
centimeters_point
centimeters_rectangle
ciceros_point
ciceros_rectangle
inches_point
inches_rectangle
measurements_point
measurements_rectangle
millimeters_point
millimeters_rectangle
percent_point
picas_point
picas_rectangle
points_point
points_rectangle
angle_measurement
You must be very carefull to use the right data type.
This is not an appscript problem! This is a Quark "feature".
If you use has's help() function for the document object you will get
exactly the info you need. Try
qxd.help('-t document')
and you will get:
========================================================================
========
Appscript Help (-t document)
Reference: app(u'/Applications/QuarkXPress/QuarkXPress.app')
------------------------------------------------------------------------
--------
Terminology for document class
Class: document -- A document
Parent:
default_document
Properties:
......
page_height : k.vertical_measurement (r/o) -- the height of a
page in this document
page_width : k.horizontal_measurement (r/o) -- the width of a
page in this document
-------
page_height and page_width are properties of the class document.
The page inherits these properties from the document.
This is another Quark "feature". The object hierachy in Quark is not
tree but a labyrinth.
I did coding with AppleScript for years. Most of them to drive
QuarkXpress and I agree with has's statments
that you have to distinguish application-related problems from
language-related problems!
For the past 2 hours I did my first lines of code with appscript. I'm
pretty sure that I will switch to appscript!
Has did a really good job!
Peter
Am 01.04.2005 um 16:23 schrieb has:
> '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/
> _______________________________________________
> Pythonmac-SIG maillist - Pythonmac-SIG at python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
>
More information about the Pythonmac-SIG
mailing list