I think I see a second problem coming down the pike. the users can add pdfs to the wrapper file through a typical open file or through drag and drop. I get that the NSOpen... allows me to expand entitlements. But does drag and drop? Is there a way to get a bookmark and ask for ongoing privileges for a path I get through drag and drop? --Matthew
On Jun 23, 2012, at 1:41 PM, Erik Stainsby wrote: > So if I understand your pattern, you are managing a single "product PDF" > which is constructed by your app based upon metadata which describes the > specific component PDFs etc that the user has chosen. Those component PDFs > reside elsewhere than within your app space, correct? > > > > On 2012-06-23, at 1:26 PM, Matthew Weinstein <mwein...@kent.edu> wrote: > >> Unfortunately that undoes the automation idea. The time saving here is that >> by just re-saving the pdf, the app when the document is opened recombines it >> based upon the rules that the user set up. Basically you're forcing the user >> to recreate the sequence of files each time anew. >> >> On Jun 23, 2012, at 1:22 PM, Kyle Sluder wrote: >> >>> On Jun 23, 2012, at 1:16 PM, Matthew Weinstein <mwein...@kent.edu> wrote: >>> >>>> The whole idea of the app is so that users can automate the combining of >>>> different PDFs; users should be able to swap out different pdfs and then >>>> the program will recombine them. The program remembers (saves in a >>>> wrapper) the pdfs that have been combined. Sort of defeats the purpose if >>>> the users can't substitute say this year's calendar for last year's. >>> >>> So your app's workflow relies on the user understanding and manipulating >>> the filesystem? Apple seem to be encouraging developers to provide >>> interfaces that don't require specific filesystem layouts. In other words, >>> you control the filesystem under your container (which the user should >>> never see) and the user controls the filesystem everywhere else (the layout >>> of which your program should not rely on). >>> >>> Instead of requiring the user to replace the files using Finder, can they >>> just replace the files using your app? You would keep the source PDFs and >>> all the combined results inside your document wrapper. >>> >>> --Kyle Sluder >>> >>>> >>>> On Jun 23, 2012, at 1:12 PM, Kyle Sluder wrote: >>>> >>>>> On Jun 23, 2012, at 12:09 PM, Matthew Weinstein <mwein...@kent.edu> wrote: >>>>> >>>>>> I think the temp.security thing will work, but I'm wondering what >>>>>> happens if a user replaces a file in the directory by one with the same >>>>>> name; does the os know it's not the original file? >>>>> >>>>> Security scoped bookmarks are attached to the file itself, so if the file >>>>> is replaced you will not be able to access the new file that exists at >>>>> that path. >>>>> >>>>> May I ask what motivated you to choose a project-oriented document >>>>> structure (components located outside the document itself) rather than a >>>>> compound document structure (PDFs copied or moved into your doc bundle)? >>>>> >>>>> --Kyle Sluder >>>>> >>>>>> >>>>>> On Jun 23, 2012, at 9:53 AM, Alex Zavatone wrote: >>>>>> >>>>>>> From what I have read in the docs, accessing files outside of the >>>>>>> approved areas/domains (music, photos, documents(?) ) will ALWAYS >>>>>>> require user interaction. >>>>>>> >>>>>>> Apple is really screwing us in this one. >>>>>>> >>>>>>> I hope that Conrad is right with his suggestion. >>>>>>> >>>>>>> On Jun 23, 2012, at 12:17 PM, Matthew Weinstein wrote: >>>>>>> >>>>>>>> Dear cocoa-dev, >>>>>>>> So I'm wondering how in the maze of sandboxed apps how to get my app >>>>>>>> to work properly. What it does is wrap around pdf files so that they >>>>>>>> can be combined, separated; etc. It doesn't actually change the >>>>>>>> original pdfs, just remembers their locations, reads them in and then >>>>>>>> writes to a different pdf (as the user requests). >>>>>>>> >>>>>>>> In addition it opens a specific wrapper on launch which contains >>>>>>>> standard elements that a user might want to add to their pdf (blank >>>>>>>> pages, etc.). The file is just a typical file that the program >>>>>>>> creates, stored at a location provided by the user, so that they can >>>>>>>> add their own elements to this wrapper. >>>>>>>> >>>>>>>> The first time the program is run, it doesn't find this special >>>>>>>> wrapper, asks the user where they want it it, they pick a spot (home >>>>>>>> or documents), the program creates a directory, copies the needed >>>>>>>> files out of its bundle, it opens the file, and all is well, the >>>>>>>> elements from the "fixings" wrapper appear in a menu on the menu bar. >>>>>>>> >>>>>>>> However, the second time the program is run, i.e., once the files have >>>>>>>> been put in place and I try to access them, I get a "257" error on >>>>>>>> [[NSDocumentController sharedDocumentController] >>>>>>>> openDocumentWithContentsOfURL: myurl display: YES error: &err]; Which >>>>>>>> seems to mean I don't have permission... >>>>>>>> >>>>>>>> It doesn't matter where the user saves the file; I get the 257 error. >>>>>>>> I did all of this because when I created the directory using the >>>>>>>> NSHomeDirectoryForUser(NSUserName()) and submitted the application, >>>>>>>> Apple complained and said I needed to ask the user where to put it; >>>>>>>> but if I do I get a 257 subsequent times the program is run. >>>>>>>> >>>>>>>> Any ideas on how to do this or get beyond the error code? >>>>>>>> >>>>>>>> --Matthew >>>> >> >> >> _______________________________________________ >> >> 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/erik.stainsby%40roaringsky.ca >> >> This email sent to erik.stain...@roaringsky.ca > _______________________________________________ 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
