Am 2008-03-18 um 20:13 schrieb has:
>> 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.
I guess it has to do with my own buggy path conversion - or perhaps
it's a problem with a SMB mounted volume.
If the file/folder is visible in Finder, it works better.
Can't trace it at the moment - working long shifts every day to get
my most urgent magazine projects to the printer.
>> 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.
Unfortunately it doesn't. Or at least not reliable.
And it's hopeless to try to teach your colleagues and customers to
use only ASCII file names - some still use slashes in file names and
leave out extensions because it worked in OS9 (one customer still
works on OS7, I guess...)
>> (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. :)
Ok, thanks, deleted it.
The other old stuff was cleaned out before, but there was no
replacement for TS, so I left it...
As I mentioned: since I got the path stuff right, everything works
(as soon as I figure out how some strange applescript reference
property works).
Now I must catch up on my Python OOP skills - I started with 2.2 and
didn't embrace a lot of new syntax since 2.3.
Also I must check whether there are appscript shortcuts to some code
I tinkered.
Otherwise I'd be ashamed to provide my code as an appscript example.
>> 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.
Ah, sorry, didn't realize that it comes from the AS dictionary
itself, I thought those were some items you couldn't wrap for Python.
>> 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.
Don't know. You do explain that behaviour. But I did understand only
after some experimenting what you mean. (Being no native speaker
doesn't help ;-)
On one hand it would be nice to get examples how to write really
asynchronous code with appscript (e.g. with PyDispatcher or Twisted),
on the other hand you normally need the seemingly linear behaviour of
appscript - I doubt if it would work to send several events to an
application in an asychronous way - perhaps to different apps, but
then you would better use subprocessing...
Oh, another FAQ:
Does appscript cache queries? (i.e. is it "expensive" to call
something.someproperty() several times, so that I should remember
that value in a variable?)
(Maybe you explain that somewhere already, but I can't find it.)
>> 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.
Of course.
I learned that Adobe's developer docs are full of errors (e.g. the
documentation of InDesign tags is missing important information and
lists a lot of tags that just don't exist "in real life"). Unicode
(or other encoding) handling of InDesign and Acrobat is horrible.
etc.
I tried to hunt down experts at Adobe shows to get some questions
answered (e.g. about Acrobat JavaScript or hybrid colors in InDesign)
- I got a lot of plainly wrong answers.
But for I don't use the latest versions I see no chance to make any
impact with bug reports or feature requests.
If I see how known experts (like Swiss PDF guru Stephan Jaeggi), who
regularly work with Adobe staff, can't manage to get simplest bugs
fixed (e.g. translation errors), or if something gets fixed in
version n.2, it appears again and worse in (n+1).0, so I don't bother
trying.
And Adobe is not the worst by far...
(Open Source rules - I guess I should switch to Scribus; but there's
no replacement for Acrobat Pro, and when I tried Scribus last time,
it and its file format weren't print production quality...)
Whined enough for today. ;-)
Greetlings from Lake Constance!
Hraban
---
http://www.fiee.net
https://www.cacert.org (I'm an assurer)
_______________________________________________
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
