Henning Hraban Ramm wrote:
>> I struggled a lot with paths containing non-ASCII characters.
>> Hmmm. Is this with the 0.18.1 release? Do you get the same problem
>> with the current appscript trunk?
>
> Sorry - since yesterday it works (with 0.18.1).
> Some problems with appscript seem to appear or disappear
> unreproducable. :-(
>
> E.g. I had big problems with Finder labels - often got "16393" as
> label_index for some tries, until finally the right number showed
> up. Can't reproduce that any more, without changing my installation.
Sounds very odd. Doubt the problem is coming from appscript itself,
unless its installation has gotten screwed up. You might check that
any older versions have been completely removed, doing a thorough
cleanout and fresh reinstall if needed. Also, where a problem is
encountered, try running the equivalent AppleScript to see if the
problem occurs there as well.
> As I posted before, it was a bit hard to find out where to apply
> which unicode conversion to file paths. (And before you advised me
> about mactypes I tried to convert Unix to Mac paths myself, which
> didn't always work.)
>
> This way works for me, hopefully it will last:
>
> myfile = mactypes.Alias(os.path.abspath(unicodedata.normalize('NFD',
> unicode(sys.argv[1], 'utf-8'))))
I'll need to look into normalisation issues when I've time, although I
would've assumed the filesystem APIs would apply any necessary
normalisation at their end.
>>> << 1 >>
>>> Why does this work:
>>> document = InDesign.make(new=k.document)
>>> document.save(to=ComposedFile(path))
>>>
>>> but not this:
>>> document =
>>> InDesign.make(new=k.document).save(to=ComposedFile(path))
>>
>> Seems to work on CS3. What are you expecting it to do vs. what is it
>> actually doing?
>
> If I chained it, it just wouldn't save.
> Again: can't reproduce the error.
The two above examples create and save the document in exactly the
same way. Python+appscript isn't like AppleScript, where the
interpreter inserts magic behaviours between lines. Could be something
else in your setup is acting up, resulting in hard-to-trace errors
cropping up elsewhere.
> I guess my path wasn't perfectly converted until today or something
> like that.
> (Or could it depend on TerminologyServer running? Will check that
> tomorrow.)
TerminologyServer is long, long gone. If you've still got a copy
kicking around then you definitely need to do some cleaning-up. :)
>>> << 2 >>
>>> Why is Finder.copy not (yet) implemented? Will it soon?
>>
>> Application-specific problems are outside the scope of appscript's
>> FAQ, but I'm going to add a "I'm having trouble scripting <name of
>> app>. What do I do now?" topic (suggested on rb-appscript-discuss)
>> pointing users to appropriate forums (AppleScript-users, etc.) as a
>> general cover-all.
>
> Ok, perhaps you could answer generally, why some items are "NOT
> AVAILABLE (YET)".
> Or did I overlook that somewhere?
Who can explain what goes on in application developers' heads? These
commands were supported in Finder on OS 9, but weren't re-implemented
when it was ported over to OS X. For whatever reason, the Finder
developers left the dictionary definitions in instead of doing the
obvious and sensible thing which would be to hide or remove them. One
of the few consistencies in scriptable applications, particularly
Carbon ones, is that they are inconsistent.
> I think the worst problem with appscript is the "strange behaviour"
> id you're used to either linear or object oriented or really
> asynchronous code - appscript looks like linear & object oriented,
> but is "a bit" asynchronous (but not like twisted's Deferreds) and
> instead of "real" objects you get those dynamic references.
The OO-like syntax can be misleading for newcomers, but dressing up
query-driven APIs in OO-ish syntax for conciseness and readability
isn't unique to appscript; e.g. SQLObject. The key to 'getting'
appscript is realising that Mac application scripting is based on RPC
+queries, and what that implies.
The problem is a communication one: either folks aren't reading the
appscript documentation, or they aren't understanding it. I know that
some folk fall into the first trap (they look at existing code
samples, and assume that since it looks like OOP, which they already
know, it must behave like it as well), and I've no doubt that others
fall into the second (since my writing is less than stellar).
Any suggestions on how to address either of these problems will be
very welcome.
> Additionally every application behaves differently and you've to
> find out what works how (or not) - or how they call something
> internally what you know with some (translated) name from GUI and
> manual...
Lousy API documentation is a chronic problem amongst scriptable
applications. File feature requests with application developers asking
for improved documentation. The more users raise this issue, the
likelier it is that developers will address it.
Cheers,
has
--
Control AppleScriptable applications from Python, Ruby and ObjC:
http://appscript.sourceforge.net
_______________________________________________
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
