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

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
>