Re: Locking an NSDocument
Re: Locking an NSDocument
- Subject: Re: Locking an NSDocument
- From: Quincey Morris <email@hidden>
- Date: Fri, 09 Sep 2011 16:34:36 -0700
On Sep 9, 2011, at 15:05 , Kyle Sluder wrote:
> I'm trying to force a document to open as locked. The use case is for
> upgrading documents from our previous file format. In the past, if the
> user tried to open an old file, we'd upgrade the document, place the
> new version alongside the old version, and open the new version. We
> can't do that in the new sandboxing world. So we thought we would open
> the old version Locked, and if the user tried to make a change we'd
> present a sheet saying the document was locked because it was in an
> older file format; the sheet would contain a "Duplicate and Upgrade"
> button.
While not claiming to have a complete (or even good) response to your question, I'll offer the following perspective:
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).
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). 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.
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?
_______________________________________________
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