Re: Locking an NSDocument
Re: Locking an NSDocument
- Subject: Re: Locking an NSDocument
- From: Kyle Sluder <email@hidden>
- Date: Fri, 09 Sep 2011 16:58:04 -0700
On Fri, Sep 9, 2011 at 4:34 PM, Quincey Morris
<email@hidden> 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 (email@hidden)
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:
This email sent to email@hidden