(moved to a new thread, because we hijacked Motti’s thread) On Nov 29, 2015, at 16:30 , dangerwillrobinsondan...@gmail.com wrote:
> But do bear in mind a doc from Apple with a last updated date that old may > have been superseded by a header comment, release notes, a WWDC presentation > or no docs at all. Sure, but what the document says *is* the behavior that Ben saw, so I’m prepared to believe it. :) I don’t think I have the time or energy to write code to test every aspect of this, but let me try to say what I think the state of play with NSDocument is. Let’s hope that if I’m still wrong about some of this, someone more knowledgeable will jump in and correct me. AFAIK there were two transitions in NSDocument architecture. First, there was the transition from “old” to “modern”, which accompanied the introduction of state restoration. The new architecture had an autosave mechanism which is now called “autosave elsewhere”. Second, there was the (optional by app) transition from “autosave elsewhere” to “autosave in place”. That means that any given Mac might have 3 different document save metaphors across its various apps (old, elsewhere, in place), not even considering slight changes arising from which version of the SDK older apps linked with. But I’m going to ignore “old” NSDocument, and just talk about the “modern” ones. — Under “autosave elsewhere”, a dirty document was autosaved into a temp folder on the same disk volume. That meant that in the event of a crash, you could recover to the last autosave, which was (typically) no more than 20 seconds old. In this case, if you File->Save the document, it is first autosaved-elsewhere, then the elsewhere file and the original file are atomically swapped, and then the original file is discarded. That ensures that the save either succeeds completely, or fails completely. If you File->Close the document, there’s a dialog asking whether you want to save or not (and this is *not* affected by the current System Preferences setting “Ask to keep changes when closing documents” — I repeat: NOT affected). If you App->Quit, then (I think), one of two things happens. With “Close windows when quitting an app” is set in System preferences, the document is File->Close’d, which means you still get an opportunity to save or not save. Without that, the document is merely autosave-elsewhere’d, and its state is preserved. This means that after a File->Close for any reason (including one implied by Quit), when the document is re-opened, it’s clean. In the last-mentioned case, with state preservation upon quit, the document is “re-opened” at the next launch just as dirty as it was at quit. IOW, in this scenario you can quit the app anytime, without disturbing your editing environment. The only fly in this ointment is that most apps don’t preserve the undo chain — it would have to be written into the document file itself, or added to the preserved state as custom data, and there could be a lot of it, plus it could be difficult to represent without memory pointers, since it’s usually just a bunch of objects. — Under “autosave in place”, documents are *always* saved. In concept, that is, what you see in the window is *already* written to disk. In practice, there’s the same 20-second autosave delay as in the other case. In this case, if you File->Save the document, it is first autosaved-in-place if necessary, and then it’s just marked clean. That’s it. (Well, there must be machinery to make this an always-succeed/always-fail proposition, too. I don’t know what that is offhand, or whether it involves copying the data to a temp file.) If you File->Close the document, then again there’s an autosave-in-place if necessary, and again that’s it. If you App->Quit, then again there’s an autosave-in-place, but state preservation (if enabled in System Preferences) is done, so that the document will re-open at relaunch. That’s what happened to Ben in Preview (and the same thing happens in TextEdit, which is also an autosaves-in-place app). He quit with a dirty document still open. The System Preferences setting “Ask to keep changes when closing documents” was off, and so the document autosaved-in-place before the quit, *and* its state was preserved. When he re-launched Preview, it therefore re-opened due to state restoration, and was “correctly” marked dirty, but that didn't have any useful effect because the undo chain was gone. You can “revert” to “last opened” at this point, but that just makes the edited document not dirty, since the edited document is what was opened. If you want to actually go back, you need to examine the history in the versions browser. So, Versions is the last piece of this. It’s what autosave-in-place relies on to avoid the need to let you “don’t save” at File->Close time. It’s too late, at that point, to avoid the actual save to the file — it’s been done already. So what you get instead, if you force the dialog by turning “Ask to keep changes when closing documents” on in System Preferences, is a “Revert Changes” button instead. So what’s the value of a manual File->Save in this case? Well, AFAIK it forces a new version to be created. Automatic autosaves-in-place don’t, or at least don’t always (I’d assume). I also assume you get a new version at File-Close. If I’ve got all this right, then that took a lot of ‘splaining. Even new, casual users are likely to be exposed to both of the modern NSDocument behavior variants, so I think it’s gotta be confusing. If we developers had decided to buy into autosave-in-place 100%, things might be easier, but I can hardly see it as compelling for us — especially when most users (I suspect) don’t have a clue what Versions is, or how to find it. After all, *Xcode* uses Versions to save changes to text files you edit, but it has *no interface* to the browser. I believe you can browse the Versions history of your source files via TextEdit, but most of us just go for SCM instead. Sorry about the long post. _______________________________________________ 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
