On Jun 23, 2012, 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. I believe "re-saving" the PDF should preserve your security-scoped bookmark, as long as the saving app preserves the file's metadata before it overwrites the contents. (Whether this works with safe-saving, I'm not sure. I believe it should, but could be wrong.) That said, could you use Automator and Folder Actions to implement your automation? This kind of filesystem-based automation is useful right now, but the trend definitely seems to be towards hiding the filesystem. --Kyle Sluder > > 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
