Hi Quincey, I have no problem with the use of the open panel ( security-scoped bookmark )for creating new documents. The problem is for pre sandboxed documents or documents that come from Windows. Having the user re-authorize each external file would be very problematic and time consuming.
What I am looking for are suggestions to best handle or avoid the re-authorization of each embedded file reference. One option may be to write a non sandbox application that would take the non sandboxed document and convert the file references to security-scoped bookmarks if this is allowed. Note; I am not trying to start a sandbox flame war. Marshall On Oct 3, 2012, at 4:34 PM, Quincey Morris wrote: > On Oct 3, 2012, at 12:44 , Marshall Houskeeper <mhouskee...@media100.com> > wrote: > >> Our plan is to use Security-Scoped Bookmarks for all new documents to store >> external file references when we go to the sandbox environment. In our use >> case, I would guess that none of the external referenced files would be >> stored in our sandbox. > > What I'm saying is, for all *new* documents, you can't create security-scoped > bookmarks unless the user has authorized each (via the open panel). Thus, > even for future documents, if they contain thousands of references via > bookmarks, then you would have had to get them through the open panel > thousands of times. > > Of course, this is the worst case. If the user is actually adding (say) > hundreds of files from a single folder, then presumably you'd might have the > user choose the folder and create a bookmark to the folder rather than the > files. > > But the point is that AFAIK: > > 1 security-scoped bookmark == 1 visit to the open panel > > Depending what your app is actually doing, this might be painful for users. > In the Final Cut scenario which Sean mentioned, I'd assume there *is* a visit > to the open panel for adding each asset (or asset folder) to the project. But > that was true even before sandboxing entered the picture -- sandboxing > doesn't really add anything new (except perhaps to force re-authorization of > locations for items in existing projects, one time). > > _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
