Re: Why is this script 'openin' stationery files.
Re: Why is this script 'openin' stationery files.
- Subject: Re: Why is this script 'openin' stationery files.
- From: Axel Luttgens <email@hidden>
- Date: Mon, 12 Sep 2011 10:12:14 +0200
Le 11 sept. 2011 à 01:48, Shane Stanley a écrit :
> On Sep 10, 2011, at 11:29 PM, Axel Luttgens wrote:
>>
>> Do you mean that the file duplication is done by LaunchServices?!?
>
> I had thought it was done by something other than the Finder, probably LaunchServices, but now I'm having serious doubts.
>
> For example, this passes the template file to the open handler:
>
> tell application "Finder"
> open (POSIX file "/Users/shane/Desktop/Test.template") using (POSIX file "/Users/shane/Desktop/Droplet.app")
> end tell
>
> As does this in AppleScriptObjC:
>
> tell current application's NSWorkspace's sharedWorkspace() to openFile_withApplication_("/Users/shane/Desktop/Test.template", "/Users/shane/Desktop/Droplet.app")
Hello Shane,
Yes, those behaviors are similar to the ones obtained with /usr/bin/open as well.
Looks like LaunchServices haven't integrated yet the concept of a stationery file (even the "stationary flag" is still saved in the file's FinderInfo attribute).
As a result, to get the "stationary behavior", the Finder must explicitly be involved in the process of opening a stationary file, either through its GUI or (adapting your above example) by sending it an 'odoc' event:
tell application "Finder" to open (POSIX file "/Users/shane/Desktop/Test.template")
Now, going further with Yvan's idea of a bug: the bug is that the Finder's handling of stationary files is very, very dumb. As soon as a file may be declared to be a stationary through its Info window, the duplicate/pass a reference to the copy behavior will blindly occur, even if this doesn't make sense. For example, a droplet being created as a viewer (as opposed to an editor), there should be no need to create a copy of the dropped file...
> This is different to the situation with aliases, where both the above pass the resolved file and not the alias, suggesting the Finder isn't involved in that decision.
Well, yes and no. Traditionally, an alias always has been an opaque construct; as a result, opening an alias file has always been synonym to opening the target, not the alias file itself. So, it could be said that the Finder is involved as well, by conforming to a general design choice.
Thanks for having looked at those matters,
Axel
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden