[Pythonmac-SIG] appscript terminology caching #2
Bob Ippolito
bob at redivi.com
Thu Oct 21 14:27:44 CEST 2004
On Oct 21, 2004, at 5:11, has wrote:
> Bob wrote:
>
>>>> appscript can install the FBA into its package,
>>>
>>> Fine with me. I'm not sure how to package it for distribution though
>>> - AFAIK distutils isn't resource fork/creator code-friendly. Advice?
>>
>> It's not. Don't use resource forks.
>
> I've not. I do have a creator code though - makes it easier for
> appscript to identify ATS.
Your creator code should be declared in the PkgInfo and Info.plist
files.. BSD copying sure won't screw up text files.
>>> Another idea: would checking an application's creation/modification
>>> date be a viable way to avoid the cache going bad when a newer
>>> version of the app is installed in exactly the same location?
>>
>> For bundled applications you would have to walk the whole application
>> tree to see if anything has changed.. It's possible to update
>> resources without touching the outer folder.
>
> Good point. Also, Steve's point that an application can gain or lose
> terminology as scriptable extensions are added or removed. Definitely
> puts the kibosh on that one.
>
> How about process id? As in: "When ATS receives a request for an
> application's terminology, if the application's process id has changed
> since the terminology was last cached, reload it." Would that cover
> the updated application scenario okay? It won't cover the extensible
> terminology situation, but even that might be partially addressable,
> e.g. by having appscript request 'fresh' terminology if it encounters
> a keyword it's not familiar with.
That sounds like a good idea. Actually.. you could register for all
application start/termination notifications and get/parse terminologies
for any application that starts. You should be able to do this with
PyObjC via NSWorkspace:
http://developer.apple.com/technotes/tn/tn2050.html
-bob
More information about the Pythonmac-SIG
mailing list