On 6 Sep 2012, at 23:27, Georg Seifert <georg.seif...@gmx.de> wrote:
> > On 06.09.2012, at 15:32, Mike Abdullah wrote: > >> On 6 Sep 2012, at 13:36, Georg Seifert <georg.seif...@gmx.de> wrote: >> >>> Hi, >>> >>> I have a problem. My app (documents based) does not support Lions Version >>> (returns NO in autosavesInPlace). This worked fine until I had to sandbox >>> my app. The problem is, that now the NSDocument autosaving tries to create >>> a file called "My Document Name (Autosaved).myExtension" next to the >>> document. But this is blocked by the sandbox. >>> >>> Is there any way to extend the permission to the autosave file or can I >>> force NSDocument to always store the autosave files in the container? >> >> What's stopping you adopting autosave-in-place? >> > I actually used autosave in place but my users did not like it at all. If you > have to open a lot files all the time just to check something, you do not > like that any mouse click might change your document and you are not asked if > you what to keep it. So let's try to nail down some of the real problems here: NSDocument's old autosave support periodically saves a copy of the document as the user works. For new, unsaved documents, that's not a problem with the sandbox. For existing documents it is though, because gets saved alongside the original. The logic is that should the program crash or similar, and the user is unable to re-open it in a normal fashion, that autosaved copy of the doc is still sitting there on the filesystem in plain sight. The user can just go and open it up and play with it. If you're absolutely desperate to keep using the old autosave system, it might be possible to use 10.8's extra entitlements to declare that you need write access to a specific filename alongside an existing one. But it's 10.8 only and I don't know if it could quite meet your needs. Another alternative would be to ask the system to autosave to an alternative location which you do have write access to. Your users lose the ability to easily spot the autosaved copy of the doc, but otherwise it should perform fine. That said, I would strongly encourage you to adopt autosave-in-place. You describe the problem in two parts: > you do not like that any mouse click might change your document Surely this applies to either saving system? > you are not asked if you want to keep it So here's the real problem it seems; you run into customers accidentally modifying documents. Normally they would be warned as they quit or close the doc, but with autosave-in-place, that doesn't happen. Some good news in 10.8: users can turn on a system preference so that they get effectively get back the warning behaviour. Closing a document will warn you if there are "unsaved" changes. However, the file on disk will already have been updated. That might bother them; I don't know. But more importantly, isn't this exactly what 10.7's concept of locked documents tried to solve? If the doc hadn't been edited in a while, it would be marked as locked. So the first time any edit occurred, a sheet popped down asking if the user wanted to go ahead with the edit, duplicate the doc or cancel. Was that not kicking in for your typical customers? Perhaps because the document was too recently edited? 10.8 does throw this out of the window. But what you could do is override -checkAutosavingSafetyAndReturnError: so that it always returns NO when a doc is first opened. If your app is primarily used as a viewer, that could be a neat way for you to always ask if the first edit is intended. _______________________________________________ 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
