Re: Bunch of CoreData based NSDocument questions.

2015-11-29 Thread Graham Cox 

> On 29 Nov 2015, at 12:20 PM, Quincey Morris 
>  wrote:
> 
> you can no longer go back to the pre-save state


There is one exception to this: Undo. If you don’t clear your undo stack on 
save, then it’s possible to undo past the last save point. I’m not sure, but I 
don’t think NSDocument clears its undo state by default on save - looking at my 
code, I’m doing this manually (or not, I have a preference for that). Not sure 
if that’s pertinent to the discussion, but it may be worth bearing in mind.

—Graham



___

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

Re: Bunch of CoreData based NSDocument questions.

2015-11-29 Thread Ben Kennedy 

> On 28 Nov 2015, at 5:20 pm, Quincey Morris 
>  wrote:
> 
> 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. [...]
> 
> 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.

This doesn't seem to square with the behaviour of, e.g., Preview.app. I hate 
this app (and the auto-save architecture in general) because it gleefully 
allows me to damage my own files without realizing it.

More specifically: open an image in Preview; crop it arbitrarily; then quit.  
Go look at the source file on disk -- it has been irreparably damaged: the crop 
was immediately saved!

Re-launch Preview, and observe that there is no way to undo this damage. As far 
as I can tell, one is forced to dig in to the Time Machine BS in order to 
resurrect the file.

This seems inconsistent with your description above: not only does Quit imply a 
Save, but there is no way to recover from it undo-wise, either.

The new-style document architecture was, and is, one of the worst UX 
regressions in the history of Mac OS.  I'm glad that most of the third-party 
apps I use have chosen to eschew it.

b


___

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

Re: Bunch of CoreData based NSDocument questions.

2015-11-29 Thread Graham Cox 

> On 30 Nov 2015, at 9:41 AM, Ben Kennedy  wrote:
> 
> The new-style document architecture was, and is, one of the worst UX 
> regressions in the history of Mac OS.  I'm glad that most of the third-party 
> apps I use have chosen to eschew it.


I know where you’re coming from on this.

I think one thing the architects of this did not really consider is that the 
act of NOT SAVING is a deliberate action on the part of the user (though 
obviously one that’s undetectable as such). I open a file, tinker around 
editing something but I don’t want to keep that change, so I deliberately DON”T 
SAVE. That’s what’s always worked for decades, but now it doesn’t. If you want 
to experiment with a change you are unlikely to want to keep, you need to do a 
duplicate up front. I just don’t think that’s the way many people’s minds think 
about their workflow.

—Graham



___

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

Re: Bunch of CoreData based NSDocument questions.

2015-11-29 Thread Shane Stanley 
On 30 Nov 2015, at 9:41 AM, Ben Kennedy  wrote:
> 
> This doesn't seem to square with the behaviour of, e.g., Preview.app. I hate 
> this app (and the auto-save architecture in general) because it gleefully 
> allows me to damage my own files without realizing it.
> 
> More specifically: open an image in Preview; crop it arbitrarily; then quit.  
> Go look at the source file on disk -- it has been irreparably damaged: the 
> crop was immediately saved!
> 
> Re-launch Preview, and observe that there is no way to undo this damage. As 
> far as I can tell, one is forced to dig in to the Time Machine BS in order to 
> resurrect the file.

System Preferences -> General, check "Ask to keep changes when closing 
documents".

-- 
Shane Stanley 



___

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

Re: Bunch of CoreData based NSDocument questions.

2015-11-29 Thread Ben Kennedy 
> On 29 Nov 2015, at 3:00 pm, Shane Stanley  wrote:
> 
> On 30 Nov 2015, at 9:41 AM, Ben Kennedy  wrote:
>> 
>> Re-launch Preview, and observe that there is no way to undo this damage. As 
>> far as I can tell, one is forced to dig in to the Time Machine BS in order 
>> to resurrect the file.
> 
> System Preferences -> General, check "Ask to keep changes when closing 
> documents".

Either I was not aware of or had forgotten about that setting, but regardless, 
it's already turned on. (The other one beside it, “close windows when quitting 
an app”, is off -- I'm not sure if that adds more subtleties to this 
confounding behaviour.)

b


___

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

Re: Bunch of CoreData based NSDocument questions.

2015-11-29 Thread Quincey Morris 
On Nov 29, 2015, at 14:21 , Graham Cox  wrote:
> 
> If you don’t clear your undo stack on save, then it’s possible to undo past 
> the last save point.

IIRC the context was that Motti proposed autosaving by doing a Core Data “save” 
operation, which writes the in-memory Core Data state to the database, then if 
the document was eventually closed without saving it would be possible to “roll 
back” the change by undoing everything since the change.

My position is that this is too dangerous — if the app crashes after such a 
save, you can’t recover the last document-saved state of the database, which is 
something earlier than the last Core Data save.


On Nov 29, 2015, at 14:41 , Ben Kennedy  wrote:
> 
> More specifically: open an image in Preview; crop it arbitrarily; then quit.  
> Go look at the source file on disk -- it has been irreparably damaged: the 
> crop was immediately saved!
> 
> Re-launch Preview, and observe that there is no way to undo this damage. As 
> far as I can tell, one is forced to dig in to the Time Machine BS in order to 
> resurrect the file.
> 
> This seems inconsistent with your description above: not only does Quit imply 
> a Save, but there is no way to recover from it undo-wise, either.

It’s a bug…

On Nov 29, 2015, at 15:00 , Shane Stanley  wrote:
> 
> System Preferences -> General, check "Ask to keep changes when closing 
> documents".

Part of the confusion comes from that preferences setting. (Mine was turned 
off, and I don’t recall ever turning it off myself.)

But there’s still a terrible, terrible bug. Even with that setting on, you can 
quit without getting a do-you-want-to-save dialog, and the document is actually 
saved, instead of just being autosaved. When you relaunch, state restoration 
causes the document to *say* it’s dirty, but it’s not really, and you can’t 
revert to the correct version. This is *not* supposed to happen.

What’s supposed to happen on Quit is that the document is *autosaved*, not 
save, so when you re-launch it’s dirty but revertible. (Undo can’t help, 
because most apps don’t preserve the undo chain across relaunches. That’s 
nothing to do with the document system.)

___

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

Re: Bunch of CoreData based NSDocument questions.

2015-11-29 Thread Shane Stanley 
On 30 Nov 2015, at 10:08 AM, Ben Kennedy  wrote:
> 
> Either I was not aware of or had forgotten about that setting, but 
> regardless, it's already turned on.

Then your claim that "there is no way to undo this damage" is incorrect. Open 
an image in Preview, crop it, and quit. Open it again and you'll see the 
document is marked dirty/Edited, and you can get back to the original either by 
clicking the close button and Revert Changes, or choosing File -> Revert 
Changes...

-- 
Shane Stanley 



___

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

Re: Bunch of CoreData based NSDocument questions.

2015-11-29 Thread Ben Kennedy 

> On 29 Nov 2015, at 3:15 pm, Shane Stanley  wrote:
> 
> Then your claim that "there is no way to undo this damage" is incorrect. Open 
> an image in Preview, crop it, and quit. Open it again and you'll see the 
> document is marked dirty/Edited, and you can get back to the original either 
> by clicking the close button and Revert Changes, or choosing File -> Revert 
> Changes...

Son of a gun, you're right! I might never have discovered this were it not for 
your recipe. How ridiculous...!

(Are you suggesting this is sensible or intuitive?! Is this what the average 
user expects? Unbelievable.)

Of course, these steps only appear to work if I haven't already moved or 
renamed the file prior to discovering the damage. It seems that once I have, 
I'm screwed.

The app has no business overwriting my original file without either a) my 
explicitly hitting save, or b) prompting me to allow a save.

b


___

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

Re: Bunch of CoreData based NSDocument questions.

2015-11-29 Thread Shane Stanley 
On 30 Nov 2015, at 10:28 AM, Ben Kennedy  wrote:
> 
> Are you suggesting this is sensible or intuitive?!

I'm not suggesting anything other than that it's not as you thought. One man's 
intuitive is another's weird. It is what it is. 

> Is this what the average user expects? 

I don't know -- I don't think many of us here really count as average users.

> The app has no business overwriting my original file without either a) my 
> explicitly hitting save, or b) prompting me to allow a save.

You might try clicking the "Close windows when quitting an app" checkbox, too.

-- 
Shane Stanley 



___

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

Re: Bunch of CoreData based NSDocument questions.

2015-11-29 Thread Quincey Morris 
On Nov 29, 2015, at 15:28 , Ben Kennedy  wrote:
> 
> (Are you suggesting this is sensible or intuitive?! Is this what the average 
> user expects? Unbelievable.)

> The app has no business overwriting my original file without either a) my 
> explicitly hitting save, or b) prompting me to allow a save.

Um, I’ll say it again. You are correct that it shouldn’t do this. It is a 
ghastly bug.

When you Quit, the document file should *not* just be silently overwritten, and 
when you re-launch, the document should be dirty and revertible to “Last 
Opened”, without requiring a trip to the version editor.

___

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

Re: Bunch of CoreData based NSDocument questions.

2015-11-29 Thread Ben Kennedy 

> On 29 Nov 2015, at 3:34 pm, Shane Stanley  wrote:
> 
>> Is this what the average user expects? 
> 
> I don't know -- I don't think many of us here really count as average users.

That's why I asked the question. If I, as a 20-year Mac power user find this 
baffling, I can only imagine that an average user would find it no more 
coherent.

> You might try clicking the "Close windows when quitting an app" checkbox, too.

Thanks; now turned on. This at least seems to provide the app an earlier 
opportunity to allude to the damage it has performed -- although it does not 
mitigate the actual insidious destruction which I want to believe, as Quincey 
postulated, is only a bug rather than deliberate design).

b


___

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

Re: Bunch of CoreData based NSDocument questions.

2015-11-29 Thread Shane Stanley 
On 30 Nov 2015, at 10:44 AM, Ben Kennedy  wrote:
> 
> If I, as a 20-year Mac power user find this baffling, I can only imagine that 
> an average user would find it no more coherent.

But an average user comes at it without that 20 years' of expectations, so 
what's intuitive to her might be totally different. It may well be that it's 
more baffling to you *because* you're a long-time power user.

-- 
Shane Stanley 



___

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

Re: Bunch of CoreData based NSDocument questions.

2015-11-29 Thread Quincey Morris 
On Nov 29, 2015, at 15:44 , Ben Kennedy  wrote:
> 
> although it does not mitigate the actual insidious destruction which I want 
> to believe, as Quincey postulated, is only a bug rather than deliberate 
> design).

Well, it turns out that I’m absolutely wrong.

I just checked the documentation:


https://developer.apple.com/library/prerelease/mac/documentation/DataManagement/Conceptual/DocBasedAppProgrammingGuideForOSX/StandardBehaviors/StandardBehaviors.html#//apple_ref/doc/uid/TP40011179-CH5-SW3
 


(It was last updated in 2012, so this is not some new change.)

Autosave-in-place *is* supposed to update an already-saved document in place. 
There is no separate autosave, and the correct way to go back is to use the 
versions browser. There is also no “Don’t Save” button in a do-you-want-to-save 
dialog. It’s a “Revert Changes” button instead. The “don’t save” concept has 
just gone away in such apps.

Either I never knew this, or I knew this but forgot since the last time I 
worked on an autosavesInPlace==YES app.

___

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