On Fri, Sep 9, 2011 at 4:34 PM, Quincey Morris <quinceymor...@rivergatesoftware.com> wrote: > 1. The "Locked" attribute belongs to the user, and is not yours (the > developer, the application, whichever) to manipulate, even with the best of > intentions. Surely, when an old-file-format document receives an editing > change in the Lion UI world, what you want to do is to immediately and > without user interaction create a new version of the document (that is, > whatever the "Save a Version…" menu item does).
The problem with that is that the actual loading process might be lossy. So if the user receives a version 1 document in an email, and only has version 2 of the application, they will never have an opportunity to use the Versions UI to see the file as Version 1 would present it, and AppKit might autosave the document as soon as it is reverted, which of course will also be a (perhaps even more) lossy process. > 2. The Duplicate solution, even if you could get there in the way you > propose, doesn't seem like the best way to proceed in the Lion UI world. > My reasoning is this: > 1. If the document happens to be locked, the normal > unlock?/cancel?/duplicate? interaction will occur (or will have occurred -- > I don't remember without looking it up exactly when this is triggered). I believe providing a custom recovery attempter from -checkAutosavingSafetyAndReturnError: will give me the opportunity to provide my own custom interaction before the standard behavior is tried: "When autosaving in place is turned on an NSDocument may invoke this method when it receives notification from its NSUndoManager that the user changed the document, or undid or redid a change. (Or it may not. NSDocument does not invoke this method for scripted changes or after some kinds of reverting.) If an error is returned it presents the error to the user, allowing the user to choose a recovery option. If the error is recovered from then it repeats this until no error is signalled, to make sure that all checks have been done. This means that when you signal an error and the user's choice of recovery option indicates that they have seen and disregarded a safety concern you must record that fact, and not do that particular safety check again. Once all errors are recovered from NSDocument continues on by invoking -updateChangeCount:, which it has done in response to NSUndoManager notifications since Mac OS 10.0. If an error is not recovered from then NSDocument invokes -[NSUndoManager undo] or -[NSUndoManager redo] to roll back the change. So, some of the NSError recovery options you let the user select, like NSDocument's own "Duplicate and "Cancel," should indicate failed recovery and that will cause the document to be unchanged afterward." > If > the document is not locked, it's editable as far as the user is concerned, > so involving the user in a decision about what to do just makes your problem > (what to do with the old format) the user's problem instead. And though > there's no *necessity* to do anything special, as a courtesy to the user it > seems desirable to preserve the document as it was before the format change, > as a separate version. > 2. Part of the value of Versions is that sweeps away all that old cruft > about sidegrading documents for reasons such as file format changes. It > relieves the user of the need to create (directly or indirectly) multiple > distinct copies of a document "just in case" something happens that creates > a new to go back. The Versions mechanism itself provides a better safety > net, and it does it automatically (or "automatically"). By "better", I mean > the user isn't faced with the file management implied by having multiple > differently named files. Leaving the old document aside would be consistent with our old behavior, but consistency isn't required or even necessarily desirable here. It just seemed like the best way to ensure the user had a clear way to fall back to a non-lossy-imported version of their file. The benefit of using the Duplicate machinery for this would be that it's now a standard system behavior that doesn't silently create new files on disk; the old file remains intact, and the new file gets autosaved to the temporary location until the user explicitly chooses to Save it, at which point they're prompted for a location. > In short, I guess, the new Versions UI metaphor relieves you of the burden > of implementing all of the old safety nets yourself. > Does that make any sense? It makes sense, but I don't know if it sufficiently handles the case of upgrading a file from a different file format, since there's no way for the Versions UI to present the original, un-upgraded version of the file—it will always be shown through the filter of upgrading. I feel like explicitly locking and duplicating the file makes the user feel safer. --Kyle Sluder _______________________________________________ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
