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

[Peter Waibel]

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
>