On Nov 28, 2015, at 14:41 , Motti Shneor <su...@bezeqint.net> wrote: > > This I don’t get. If that’s not a close what is a ‘close'… the document > disappears, windows close and disappear
I’ll think about the other things you wrote, but I’ll answer this right now, since it’s an important conceptual part of the “modern” NSDocument behavior. There are 3 different operations that are significant to the user: 1. Quit. This is intended to preserve all of the current state so that it can be restored on relaunch. The idea is that the user can quit without changing anything that’s going on, then re-launch and be exactly where he was. As a consequence, there’s no saving of documents, since that does change what’s going on. (For example, after you save, you can’t revert any more. Saving may have other side effects, too.) Also, the windows go away, because the app goes away. 2. Save. This is a user-initiated action that causes the on-disk document state to be updated, and you can no longer go back to the pre-save state (except via Versions, but that’s a different matter). Note that when autosavesInPlace==YES, an autosave is most definitely NOT a save from the UI point of view. It’s more like a forced write of memory to a swap file. 3. Close. This is a user-initiated action that says that the *user* doesn’t want the document window to be open any more. Since there is no state restoration after a user-initiated Close, there has to be a dialog to ask what to do with unsaved changes, and the options are to save or not save. What I previously called the “close machinery” are the pieces of behavior that implement this, and they provide intervention points for the developer, such as shouldClose…/willClose…/didClose… methods. None of this happens at Quit. The virtue of this system is that a user can quit the app without having to decide whether to save. Because of autosaving, app crashing is nearly as safe, because it’s like a quit and relaunch, except if a final autosave wasn’t done before the crash the restored state will be about 20 seconds old. That’s what I meant by saying that a Close implies a Save (or not, if the user chooses to not save), but a Quit does not imply a Close or a Save. A Quit is *intended* to leave all documents unsaved, though without losing the current unsaved state, if you implement restorability properly. This is simply the architecture of the modern document system. You may not agree with the design choices, but it’s not wrong that it’s designed according to these choices. I do think that the current Quit behavior, where the documents/windows are discarded before you get a chance to refuse to terminate, is an out and out bug in ‘terminate:’. Documents should probably have their autosaves started before you’re notified, but there’s no real reason AFAICT why the document and windows can’t stay in place until after. Unfortunately, even if Apple accepts this is a bug, it’s unlikely to be repaired on any timeline that helps you get your app finished. As a workaround, you could have your applicationShouldTerminate: method be aware that documents (might) have closed already. If you keep track of what document is currently using the microscope, then you could simply re-open the document on behalf of the user. Of course, as before, this means you have to move any non-saveable state out of the document into the application itself. I also note that you haven’t talked about what happens when there’s more than one document open? Which one corresponds to the microscope state? If your answer is, say, that users only ever use one document at a time, I’d repeat the essence of what I said before — that this is a “design smell” that suggests the NSDocument metaphor is not serving you well. _______________________________________________ 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
