Hi Sorry for not answering earlier. I was to busy with other things. Am 07.09.2012 um 15:36 schrieb Mike Abdullah:
> > 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. Can someone give me a hint on how to do that? > 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? No, with the new style autosaving, the file changes on disk without asking the user. >> 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. > Thanks Georg _______________________________________________ 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
