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
