Re: Bunch of CoreData based NSDocument questions.

[Quincey Morris]

On Nov 30, 2015, at 15:18 , Quincey Morris 
 wrote:
> 
> (moved to a new thread, because we hijacked Motti’s thread)

Except that I forgot to change the subject after all. Oops.

___

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.

[Quincey Morris]

(moved to a new thread, because we hijacked Motti’s thread)

On Nov 29, 2015, at 16:30 , dangerwillrobinsondan...@gmail.com wrote:

> But do bear in mind a doc from Apple with a last updated date that old may 
> have been superseded by a header comment, release notes, a WWDC presentation 
> or no docs at all. 

Sure, but what the document says *is* the behavior that Ben saw, so I’m 
prepared to believe it. :)

I don’t think I have the time or energy to write code to test every aspect of 
this, but let me try to say what I think the state of play with NSDocument is. 
Let’s hope that if I’m still wrong about some of this, someone more 
knowledgeable will jump in and correct me.

AFAIK there were two transitions in NSDocument architecture. First, there was 
the transition from “old” to “modern”, which accompanied the introduction of 
state restoration. The new architecture had an autosave mechanism which is now 
called “autosave elsewhere”. Second, there was the (optional by app) transition 
from “autosave elsewhere” to “autosave in place”.

That means that any given Mac might have 3 different document save metaphors 
across its various apps (old, elsewhere, in place), not even considering slight 
changes arising from which version of the SDK older apps linked with. But I’m 
going to ignore “old” NSDocument, and just talk about the “modern” ones.

— Under “autosave elsewhere”, a dirty document was autosaved into a temp folder 
on the same disk volume. That meant that in the event of a crash, you could 
recover to the last autosave, which was (typically) no more than 20 seconds old.

In this case, if you File->Save the document, it is first autosaved-elsewhere, 
then the elsewhere file and the original file are atomically swapped, and then 
the original file is discarded. That ensures that the save either succeeds 
completely, or fails completely. If you File->Close the document, there’s a 
dialog asking whether you want to save or not (and this is *not* affected by 
the current System Preferences setting “Ask to keep changes when closing 
documents” — I repeat: NOT affected). If you App->Quit, then (I think), one of 
two things happens. With “Close windows when quitting an app” is set in System 
preferences, the document is File->Close’d, which means you still get an 
opportunity to save or not save. Without that, the document is merely 
autosave-elsewhere’d, and its state is preserved.

This means that after a File->Close for any reason (including one implied by 
Quit), when the document is re-opened, it’s clean. In the last-mentioned case, 
with state preservation upon quit, the document is “re-opened” at the next 
launch just as dirty as it was at quit. IOW, in this scenario you can quit the 
app anytime, without disturbing your editing environment. The only fly in this 
ointment is that most apps don’t preserve the undo chain — it would have to be 
written into the document file itself, or added to the preserved state as 
custom data, and there could be a lot of it, plus it could be difficult to 
represent without memory pointers, since it’s usually just a bunch of objects.

— Under “autosave in place”, documents are *always* saved. In concept, that is, 
what you see in the window is *already* written to disk. In practice, there’s 
the same 20-second autosave delay as in the other case.

In this case, if you File->Save the document, it is first autosaved-in-place if 
necessary, and then it’s just marked clean. That’s it. (Well, there must be 
machinery to make this an always-succeed/always-fail proposition, too. I don’t 
know what that is offhand, or whether it involves copying the data to a temp 
file.) If you File->Close the document, then again there’s an autosave-in-place 
if necessary, and again that’s it. If you App->Quit, then again there’s an 
autosave-in-place, but state preservation (if enabled in System Preferences) is 
done, so that the document will re-open at relaunch.

That’s what happened to Ben in Preview (and the same thing happens in TextEdit, 
which is also an autosaves-in-place app). He quit with a dirty document still 
open. The System Preferences setting “Ask to keep changes when closing 
documents” was off, and so the document autosaved-in-place before the quit, 
*and* its state was preserved. When he re-launched Preview, it therefore 
re-opened due to state restoration, and was “correctly” marked dirty, but that 
didn't have any useful effect because the undo chain was gone. You can “revert” 
to “last opened” at this point, but that just makes the edited document not 
dirty, since the edited document is what was opened. If you want to actually go 
back, you need to examine the history in the versions browser.

So, Versions is the last piece of this. It’s what autosave-in-place relies on 
to avoid the need to let you “don’t save” at File->Close time. It’s too late, 
at that point, to avoid the actual save to the file — it’s been done already. 
So what you get instead, if you force 

Re: Bunch of CoreData based NSDocument questions.

[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

Re: Bunch of CoreData based NSDocument questions.

[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.

[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.

[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.

[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.

[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.

[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.

[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.

[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.

[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.

[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.

[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.

[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.

[Quincey Morris]

On Nov 28, 2015, at 14:41 , Motti Shneor  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

Re: Bunch of CoreData based NSDocument questions.

[Gary L. Wade]

I don't remember the details, but I seem to recall you having to override some 
methods in NSDocument (saving, closing, etc.) and possibly NSApplication 
terminate to get the behavior it sounds like you require. The app I worked on 
wanted to make sure the user had an option to submit an action to an outside 
service even though the data was saved.
--
Gary L. Wade (Sent from my iPad)
http://www.garywade.com/

> On Nov 26, 2015, at 10:41 PM, Motti Shneor  wrote:
> 
> He hits "Quit" by mistake, and the whole thing pops and disappears. He'll 
> have to open the application and re-do half an hour's work to bring his setup 
> to the previous state. Nothing was yet saved - because most of this work is 
> outside the computer. Only the user can align these two simultaneous flows of 
> action.

___

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.

[Quincey Morris]

On Nov 26, 2015, at 22:41 , Motti Shneor  wrote:
> 
> So -- I MUST warn him and allow him to cancel this quit command. 
> unfortunately, the @$@$@ NSDocument architecture insists I'm not to be 
> involved, and shortcuts even the ApplicationDelegate 
> "applicationShouldTerminate" for me, happily autosaving what's dirty, and 
> quitting immediately. 


I’ve been looking into this a bit, and the situation is a bit more complicated 
than I thought.

On re-reading the documentation, I see that the default for 
NSSupportsSuddenTermination is NO, so this issue is NOT caused by sudden 
termination.

With autosavesInPlace==YES, you *do* have an opportunity to cancel app 
termination when there are dirty documents. I’ve just tried this in a brand new 
project, and it works fine. I suspect that you implemented the delegate method 
with the wrong signature (it has one parameter), but if not I can’t explain why 
the delegate method wasn’t called when you tried it.

However, there is some NSDocument behavior that’s affected by the app trying to 
quit (i.e. terminate: being called), but not affected by whether the app 
actually quits. Specifically, when the app tries to quit, with 
autosavesInPlace==YES, the NSDocument machinery is *first* informed that the 
app wants to quit. At this point, it autosaves all documents, then discards all 
document windows and the document object itself.

This is semantically *not* a close, either of the windows or the document, so 
none of the close machinery is invoked. This probably will surprise you, but I 
guess the point is that autosavesInPlace==YES *implies* that the document and 
its windows are restorable, and you don’t get any control over that. By the 
time your delegate method is called, it’s too late to prevent the document 
being discarded.

The news isn’t completely bad, though. If a previous-saved document is 
discarded in this way, you can get the document back by just opening it again — 
it will come back still dirty, if it was before. If your app doesn’t discard 
the microscope state when a document disappears (which it might already, or it 
sounds like it could if it wanted to), then reopening the document should get 
the user back to where he was. In this scenario, you would discard the 
microscope state when the document *closes* through the regular close machinery.

There are two problems with all this:

1. If the document has never been saved (is untitled), if you try to quit the 
app, the autosaved untitled document is written to disk, but the only way to 
get it back again (AFAICT) is to really quit the app and re-launch it. That 
means of course losing the microscope state. You might be able to mitigate this 
by forcing an immediate save when a new document is created, so the user never 
sees any untitled documents.

2. Because you’re using XXPersistentDocument, autosaving is going to be slow. I 
don’t see any direct solution to this, because autosavesInPlace==YES autosaving 
just wasn’t designed for a document based on a database. If you were using your 
own database directly, you could possibly arrange to do something with 
checkpoints or rollbacks, but I think you’re out of luck when using Core Data 
with the NSDocument architecture.

I still think you’d be better off to look for a way to have documents that 
contain something like a delta to the database. Separately, you would have 
non-document state that kept track of the hardware state, as long as the app 
was running. Then, autosaving or saving the document would write the delta to 
disk, and closing (or discarding) the document would be recoverable. The only 
check you’d have to make when the document was re-opened is that the hardware 
state hasn’t changed since the last autosave/save. (Presumably you have some 
way to know when the hardware state changes, otherwise you wouldn’t be able to 
deal with the case where someone changes the microscope setup while a document 
is open and active.)

I’m sure what I’m suggesting won’t actually work for you in detail, because I’m 
sure the details of what you’re doing are more complicated and/or more 
constrained. But I really don’t see a solution to your autosave/save 
performance issue without some way around copying the database.

HTH

___

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.

[Motti Shneor]

Thanks Ernesto. Of course I cleanup. That's not my problem. I want to DENY the 
quit. I want the user to be asked, and be able to cancel the quit - because the 
USER is in the middle of an important action, despite the fact the document is 
autosaved, and can be safely closed.

I am not worried about document integrity - rather on User's health. 

There is more to "preserving state" than just saving documents. In my case, 
user calibrates a microscope (half an hour's work), brings a sample, and drives 
it carefully until he sees what's to be measured (onscreen, on one of my 
document windows), then starts measuring some creature, then...

He hits "Quit" by mistake, and the whole thing pops and disappears. He'll have 
to open the application and re-do half an hour's work to bring his setup to the 
previous state. Nothing was yet saved - because most of this work is outside 
the computer. Only the user can align these two simultaneous flows of action.

So -- I MUST warn him and allow him to cancel this quit command. unfortunately, 
the @$@$@ NSDocument architecture insists I'm not to be involved, and shortcuts 
even the ApplicationDelegate "applicationShouldTerminate" for me, happily 
autosaving what's dirty, and quitting immediately. 

I am very frustrated with this, and I fail to see where to "override" to change 
this behavior. In the past Apple engineers were modest enough to design their 
system flexible enough for different uses. Now, much like old Microsoft - they 
just decide what's best for you - and enforce.

I really wish someone from Apple would help here on this list.
On 23 בנוב 2015, at 12:04, Ernesto Giannotta wrote:

> Have you tried this (in your Persistent document subclass)?
> 
> - (void)close
> {
> 
>// we're about to close this document but we have to do some housekeeping
>[self cleanup];
>[super close];
> 
> }
> 
>> On 23-Nov-2015, at 07:41, Motti Shneor  wrote:
>> 
>> Problem is - the application quits immediately even when there are dirty 
>> documents open!!! the @#$@#$ document "architecture" feels free to quit 
>> because all has been "AutoSaved". not "Saved". I just want the old behavior 
>> - you should not be able to quit with dirty documents. That's all.
>> 
>> I do have, of course, validation on saves (Hmmm CoreData has, and I 
>> added my overrides). But happy-happy-document-architecture doesn't really 
>> care.
>> 
>> 
> 
> Cool Runnings,
> Erne.

Motti Shneor
-
Ceterum censeo Microsoftinem delendam esse





___

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.

[Quincey Morris]

On Nov 23, 2015, at 22:34 , Motti Shneor  wrote:
> 
> All that […]

I think perhaps you’re making my argument for me. ;) 

Much of what you say *demonstrates* the difficulty of using a NSDocument-based 
design for your app. (Core Data makes it harder, because it does slow 
autosavesInPlace autosaving due to the file copy, but you’ve outlined other 
problems that don’t necessarily arise from Core Data.) Every way you turn, you 
find a NSDocument assumption that your app doesn’t conform to, and something 
doesn’t work right as a result.

I think there are parts of your app that NSDocument makes a good fit. It sounds 
like there are project “workspaces” that describe a working environment, and 
these would be good candidates for NSDocument. But the central problem you 
face, IMO (and I’d be happy for anyone to jump in and tell me I’m wrong) is 
that you don’t have a good solution at hand for how to handle the committing 
and reversion of updates to the database.


___

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.

[Motti Shneor]

> On Nov 24, 2015, at 00:14, Quincey Morris 
>  wrote:
> 
> On Nov 23, 2015, at 12:50 , Motti Shneor  > wrote:
>> 
>> Any references to that old discussion? I’d like to read it. However, I think 
>> there should be a reasonable way to provide close-enough interpretation to 
>> NSDocument’s view of documents using CoreData's persistence. Database here 
>> is only means for partial saving of changes, without re-serializing the 
>> whole document. In the past there was a whole genre of applications who 
>> worked with very little Memory, by doing the same thing - reading small 
>> parts of their document into memory, and writing small changes to the 
>> document one at a time. Surely, the Document architecture acknowledges such 
>> applications.
> 
> No, it was in the vague past.
> 
> In the NSDocument metaphor, you must keep changes to a file (since the last 
> save) separate from the file (in its state at the last save). Without that, 
> you cannot revert, and you cannot close the document without saving. If 
> you’re saving by applying the changes to a copy, you can fulfill the 
> reversion/don’t-save requirement, because the saved document doesn’t replace 
> the original until the last moment, *and* the replacement is an atomic file 
> system operation that can only fully succeed or fully fail.
> 
All that only makes sense for in-memory documents. Reverting was well known, 
supported and implemented before this architecture, by throwing away unsaved 
changed. That of course doesn’t cover “Autosave” in its current meaning.

> When you use a database with NSDocument, you can update the original file in 
> place safely (assuming the database has transactions that can roll back an 
> incomplete write), so there’s no need to copy the database for that reason.

Right

> However, you can’t autosave, because that implies the ability to revert.

But Cocoa undo-manager lives well beyond the “Save” and can easily provide 
Reverting of “autosaved” (meaning, core-data-saved but not “NSDocuent saved” 
data).

> Your current autosave is getting the ability to revert by making a copy of 
> the database. If you don’t want that, you can’t autosave, period, since Core 
> Data has no user-restorable checkpoints (AFAIK).

User restorable checkpoints can easily be found in the undo manager. If you 
only clear your undo stack when NSDocument-Saving, you’re done.

> 
> If you turn off autosavesInPlace, then you’ll have the old behavior, but 
> you’ll have to trust Core Data never to corrupt your database if the app (or 
> the system) dies in the middle of a save.

Tried that too - a zillion other niceties and standard UI of modern NSDocument 
disappear with that. You can’t use the document window’s title for moving, 
renaming, copying etc. You lose the “save as…” for some reason, and many other 
weirdnesses. 

> 
>> My issue seems different, and can also be easily reproduced in other apps 
>> (e.g. TextEdit). Quitting it with a dirty document will quit immediately, 
>> and on next launch the document will be open with all last-session’s 
>> changes, and the dirty flag on. The last autosaved state can be used to 
>> “Save” the changes from previous session.
> 
> I’m sorry, I always get this wrong. It’s behaving correctly according to the 
> autosavesInPlace==YES paradigm.

Yes.

> 
> In this case, quitting the app does *not* cause any documents to be saved (or 
> the user to be prompted to save), ever. It simply quits the app (well, it 
> does an autosave first, if the document state has changed since the most 
> recent autosave), and when you start the app again, the document is restored 
> to its previous UI state, with the same windows open and the same dirtiness.
> 

But it kills my application state that is not persisted. I’ll explain. I have 
my document (call it database if you want). I have an open “satellite” window 
open, related to that document, showing live microscope data, and the user 
(researches) performs complicated measurement of microscopic object, by drawing 
polygons and bezier curves over identified objects, then adjusts them, then 
completes his measurement to add data to the database. This window is NOT 
tagged as one who “closes the document” because it should not. If the user 
closes this microscope-view window - he’s being asked what to do with the 
incomplete measurement onscreen. But if the user presses Cmd-Q — everything 
just disappears immediately, losing the measurement, the track of where he was 
measuring, and lots of stuff that is not persistent. This is plain ugly - and I 
want to prevent this, but going the same route on quit, as the route of closing 
the window. 


> The reasoning behind this is that (in modern apps) it doesn’t matter whether 
> it’s actually running or not, so long as it can be restored to exactly the 
> most recent UI state if it re-launches.

As you see — it can’t. Maybe I should go the extra mile and learn how to 
preserve my full state? It i

Re: Bunch of CoreData based NSDocument questions.

[Quincey Morris]

On Nov 23, 2015, at 12:50 , Motti Shneor  wrote:
> 
> Any references to that old discussion? I’d like to read it. However, I think 
> there should be a reasonable way to provide close-enough interpretation to 
> NSDocument’s view of documents using CoreData's persistence. Database here is 
> only means for partial saving of changes, without re-serializing the whole 
> document. In the past there was a whole genre of applications who worked with 
> very little Memory, by doing the same thing - reading small parts of their 
> document into memory, and writing small changes to the document one at a 
> time. Surely, the Document architecture acknowledges such applications.

No, it was in the vague past.

In the NSDocument metaphor, you must keep changes to a file (since the last 
save) separate from the file (in its state at the last save). Without that, you 
cannot revert, and you cannot close the document without saving. If you’re 
saving by applying the changes to a copy, you can fulfill the 
reversion/don’t-save requirement, because the saved document doesn’t replace 
the original until the last moment, *and* the replacement is an atomic file 
system operation that can only fully succeed or fully fail.

When you use a database with NSDocument, you can update the original file in 
place safely (assuming the database has transactions that can roll back an 
incomplete write), so there’s no need to copy the database for that reason. 
However, you can’t autosave, because that implies the ability to revert. Your 
current autosave is getting the ability to revert by making a copy of the 
database. If you don’t want that, you can’t autosave, period, since Core Data 
has no user-restorable checkpoints (AFAIK).

If you turn off autosavesInPlace, then you’ll have the old behavior, but you’ll 
have to trust Core Data never to corrupt your database if the app (or the 
system) dies in the middle of a save.

> My issue seems different, and can also be easily reproduced in other apps 
> (e.g. TextEdit). Quitting it with a dirty document will quit immediately, and 
> on next launch the document will be open with all last-session’s changes, and 
> the dirty flag on. The last autosaved state can be used to “Save” the changes 
> from previous session.

I’m sorry, I always get this wrong. It’s behaving correctly according to the 
autosavesInPlace==YES paradigm.

In this case, quitting the app does *not* cause any documents to be saved (or 
the user to be prompted to save), ever. It simply quits the app (well, it does 
an autosave first, if the document state has changed since the most recent 
autosave), and when you start the app again, the document is restored to its 
previous UI state, with the same windows open and the same dirtiness.

The reasoning behind this is that (in modern apps) it doesn’t matter whether 
it’s actually running or not, so long as it can be restored to exactly the most 
recent UI state if it re-launches.

So the problem isn’t that it’s quitting, but that your document isn’t being 
restored properly when it reopens (if it isn’t — maybe it is??). That might be 
because NSPersistentDocument (or your custom clone of it) doesn’t support state 
restoration at all, or because you haven’t implemented the custom restoration 
you need to really get back to where you started.

It’s beginning to sound like autosavesInPlace==NO might be a good starting 
point for clearing your list of problems.

___

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.

[Motti Shneor]

> On Nov 23, 2015, at 09:23, Quincey Morris 
>  wrote:
> 
> On Nov 22, 2015, at 22:41 , Motti Shneor  > wrote:
> 
>> I wish I knew enough to write my own MyPersistentDocument
> 
> The problem is that the way NSDocuments are used is semantically different 
> from the way databases are used, and you *cannot* reconcile the two across 
> all the functions on the NSDocument-based File menu. (This was an old 
> discussion.)

Any references to that old discussion? I’d like to read it. However, I think 
there should be a reasonable way to provide close-enough interpretation to 
NSDocument’s view of documents using CoreData's persistence. Database here is 
only means for partial saving of changes, without re-serializing the whole 
document. In the past there was a whole genre of applications who worked with 
very little Memory, by doing the same thing - reading small parts of their 
document into memory, and writing small changes to the document one at a time. 
Surely, the Document architecture acknowledges such applications.
> 
>> Problem is - the application quits immediately even when there are dirty 
>> documents open!!! the @#$@#$ document "architecture" feels free to quit 
>> because all has been "AutoSaved". not "Saved". I just want the old behavior 
>> - you should not be able to quit with dirty documents. That's all.
> 
> You are probably falling foul of Sudden Termination:
> 
>   
> https://developer.apple.com/library/prerelease/watchos/documentation/Cocoa/Reference/Foundation/Classes/NSProcessInfo_Class/#//apple_ref/doc/uid/2316-SW3
>  
> 

> You can try opting out of this completely, or opting out temporarily. Or 
> possibly the change count type I suggested doesn’t cause the opt-out behavior 
> in NSDocument, in which case you could try NSDocumentChangeDone instead. Or 
> possibly the change count has to be updated later.
> 

Just turned off sudden-termination for my App (setting 
NSSupportsSuddenTermination to “NO” in my info.plist)  to no avail. 

My issue seems different, and can also be easily reproduced in other apps (e.g. 
TextEdit). Quitting it with a dirty document will quit immediately, and on next 
launch the document will be open with all last-session’s changes, and the dirty 
flag on. The last autosaved state can be used to “Save” the changes from 
previous session.

I found this in NSDocument.h 

The default implementation of this method has two rather different behaviors. 
If [[self class] autosavesInPlace] returns YES and [self fileURL] returns 
non-nil then it simply invokes [self autosaveWithImplicitCancellability:NO 
completionHandler:aCompletionHandler] if [self hasUnautosavedChanges] returns 
YES after making sure that any editor registered using Cocoa Bindings' 
NSEditorRegistration informal protocol has committed its changes. Otherwise it 
presents a panel giving the user the choice of canceling, discarding changes, 
or saving. In that case the shouldClose value passed to the delegate will be 
YES if the document was not modified in the first place, or the user chose to 
discard modifications, or chose to save and the saving was successful. NO will 
be passed if the user chose to cancel the operation or saving was unsuccessful. 
Because -saveDocumentWithDelegate:didSaveSelector:contextInfo: is used, an 
alert panel will be presented before the delegate is messaged if saving is 
attempted but does not succeed.
*/
- (void)canCloseDocumentWithDelegate:(id)delegate 
shouldCloseSelector:(SEL)shouldCloseSelector contextInfo:(void *)contextInfo;


While BSManagedDocument open source class I’m using implements this method, It 
is never called in my app. I set up a breakpoints, and added NSLog lines - it’s 
never called, no matter what.

I may be plain stupid, but I can’t understand  the above description especially 
in my context. I can’t even make the break into the “two rather different 
behaviors”. Could anyone please shed light on this? 

Details of my application:  
1. autoSavesInPlace returns YES;
2. [self fileURL] will also return non-nil object.
3. [self hasUnautosavedChanges] will probably return NO
4. I have 2 (or more window controllers with their windows open), only one - 
main window - will return YES for closing the document when it is closed.




___

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.

[Ernesto Giannotta]

Have you tried this (in your Persistent document subclass)?

- (void)close
{

// we're about to close this document but we have to do some housekeeping
[self cleanup];
[super close];

}

> On 23-Nov-2015, at 07:41, Motti Shneor  wrote:
> 
> Problem is - the application quits immediately even when there are dirty 
> documents open!!! the @#$@#$ document "architecture" feels free to quit 
> because all has been "AutoSaved". not "Saved". I just want the old behavior - 
> you should not be able to quit with dirty documents. That's all.
> 
> I do have, of course, validation on saves (Hmmm CoreData has, and I added 
> my overrides). But happy-happy-document-architecture doesn't really care.
> 
> 

Cool Runnings,
Erne.
___

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.

[Quincey Morris]

On Nov 22, 2015, at 22:41 , Motti Shneor  wrote:

> I wish I knew enough to write my own MyPersistentDocument

The problem is that the way NSDocuments are used is semantically different from 
the way databases are used, and you *cannot* reconcile the two across all the 
functions on the NSDocument-based File menu. (This was an old discussion.)

> Problem is - the application quits immediately even when there are dirty 
> documents open!!! the @#$@#$ document "architecture" feels free to quit 
> because all has been "AutoSaved". not "Saved". I just want the old behavior - 
> you should not be able to quit with dirty documents. That's all.

You are probably falling foul of Sudden Termination:


https://developer.apple.com/library/prerelease/watchos/documentation/Cocoa/Reference/Foundation/Classes/NSProcessInfo_Class/#//apple_ref/doc/uid/2316-SW3

You can try opting out of this completely, or opting out temporarily. Or 
possibly the change count type I suggested doesn’t cause the opt-out behavior 
in NSDocument, in which case you could try NSDocumentChangeDone instead. Or 
possibly the change count has to be updated later.

___

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.

[Motti Shneor]

On 22 בנוב 2015, at 23:23, Quincey Morris wrote:

> On Nov 22, 2015, at 11:44 , Motti Shneor  wrote:
>> 
>> 1. My app supports autosave in-place. This means each "save" practically 
>> recreates the whole document as temporary file, then replaces the document 
>> with the new one. Such behavior is reasonable for a relatively small 
>> document -not for my ever growing databases who easily reach 250MB.  What is 
>> the point in using SQL persistence, with all its glorious transactions, and 
>> rollbacks, if CoreData persistence isn't used at all for autosaving? Saves 
>> will get slower and slower as document becomes bigger and bigger, not to 
>> mention the size of document-versions, and although BSManagedDocument saves 
>> in the background - this seems really awkward. Is there a better solution? 
> 
> No joke, my advice is “don’t use Core Data”.

CoreData has shorten this application's development cycle from years to 7 weeks 
of intense programming. It is a big application, with many aspects, including  
Microscopy imaging, measurements on live video, accumulating data while 
measuring it in database, and performing deep analysis over the accumulated 
data, exports, imports, lot's of UI and more.

CoreData It is handling most aspects of my complex data scheme. Tons of 
relations and all. CoreData is great in object-graph management, and isn't bad 
at all at persisting too. Unfortunately, Apple has removed the original 
engineers from that project long time ago and the integration of CoreData with 
the document architecture is very neglected.

Previous iterations of this program (It's its 3rd incarnation - a 25 years 
ongoing project) didn't use CoreData, but took years to write, and were way 
more fragile.

It is impractical for me to give up CoreData on this project.

> 
> If you must use Core Data, then my advice is “don’t use the NSDocument 
> architecture”. The point of what you say above is that the NSDocument 
> architecture doesn’t actually match your *database* application design. In 
> that case, why not use Core Data alone, and implement the 
> nearly-but-not-quite document behavior yourself?

On my other side, My "DataBase" is really a document. self-contained, has a 
main window and several "satellite" windows, and there are several documents 
being open at the same time (for different researchers, using several 
microscopes in the same laboratory, taking turns at the computer). So it was SO 
convenient... 

I can write my own document management, but that takes lots of time and 
thinking, and does NOT work well with the OS's ever-developing requirements to 
integrate well with sleeping, waking, rollbacks, versioning, sandboxing, 
shut-downs, etc. etc. I DO WANT as much as I can get from Cocoa. 

I wish I knew enough to write my own MyPersistentDocument - but as I said - 
documentation is almost impossible to grasp (taking both sides - CoreData and 
Document architecture into consideration).

> 
>> 2. I must still support user explicit "Save" commands, because I allow 
>> auto-saving temporary invalid states of my model, and only validate and 
>> confirm integrity upon "real" saves. For that, I want to force the user to 
>> Save/Revert/Cancel changes when he closes the document, or quits the 
>> application.  
> 
> The first thing that springs to mind would be to mark the document dirty 
> after any autosave operation that saves unvalidated data. For example, invoke 
> updateChangeCount: with the parameter NSChangeReadOtherContents.
> 

Problem is - the application quits immediately even when there are dirty 
documents open!!! the @#$@#$ document "architecture" feels free to quit because 
all has been "AutoSaved". not "Saved". I just want the old behavior - you 
should not be able to quit with dirty documents. That's all.

I do have, of course, validation on saves (Hmmm CoreData has, and I added 
my overrides). But happy-happy-document-architecture doesn't really care.

> I’m assuming you ensure validation on non-autosave saves. If not, your basic 
> approach is flawed anyway.
> 

Motti Shneor
-
Ceterum censeo Microsoftinem delendam esse




___

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.

[Quincey Morris]

On Nov 22, 2015, at 11:44 , Motti Shneor  wrote:
> 
> 1. My app supports autosave in-place. This means each "save" practically 
> recreates the whole document as temporary file, then replaces the document 
> with the new one. Such behavior is reasonable for a relatively small document 
> -not for my ever growing databases who easily reach 250MB.  What is the point 
> in using SQL persistence, with all its glorious transactions, and rollbacks, 
> if CoreData persistence isn't used at all for autosaving? Saves will get 
> slower and slower as document becomes bigger and bigger, not to mention the 
> size of document-versions, and although BSManagedDocument saves in the 
> background - this seems really awkward. Is there a better solution? 

No joke, my advice is “don’t use Core Data”.

If you must use Core Data, then my advice is “don’t use the NSDocument 
architecture”. The point of what you say above is that the NSDocument 
architecture doesn’t actually match your *database* application design. In that 
case, why not use Core Data alone, and implement the nearly-but-not-quite 
document behavior yourself?

> 2. I must still support user explicit "Save" commands, because I allow 
> auto-saving temporary invalid states of my model, and only validate and 
> confirm integrity upon "real" saves. For that, I want to force the user to 
> Save/Revert/Cancel changes when he closes the document, or quits the 
> application.  

The first thing that springs to mind would be to mark the document dirty after 
any autosave operation that saves unvalidated data. For example, invoke 
updateChangeCount: with the parameter NSChangeReadOtherContents.

I’m assuming you ensure validation on non-autosave saves. If not, your basic 
approach is flawed anyway.

___

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

Bunch of CoreData based NSDocument questions.

[Motti Shneor]

Hi Everyone. 

I develop a Docuent-based Mac application for scientific use, using the 
BSManagedDocument open-source, which provides many of the modern behaviors of 
UIManagedDocument on Mac (whereas NSPersistentDocument has been neglected for 
ages). Mainly what I wanted from BSManagedDocument was its support for  
document packaging, To allow adding external records to my CoreData entities.

I have a few problems, but I can't find my way in th documentation of the 
document architecture. Please bare with me if these questions are novice's 
questions. 

1. My app supports autosave in-place. This means each "save" practically 
recreates the whole document as temporary file, then replaces the document with 
the new one. Such behavior is reasonable for a relatively small document -not 
for my ever growing databases who easily reach 250MB.  What is the point in 
using SQL persistence, with all its glorious transactions, and rollbacks, if 
CoreData persistence isn't used at all for autosaving? Saves will get slower 
and slower as document becomes bigger and bigger, not to mention the size of 
document-versions, and although BSManagedDocument saves in the background - 
this seems really awkward. Is there a better solution? 

2. I must still support user explicit "Save" commands, because I allow 
auto-saving temporary invalid states of my model, and only validate and confirm 
integrity upon "real" saves. For that, I want to force the user to 
Save/Revert/Cancel changes when he closes the document, or quits the 
application.  

When closing the document's main window - all is well. My window-controller 
overrides get called, user is presented with a dialog, etc. But when the user 
chooses to Quit the application - it quits immediately, and never calls any of 
the NSDocumentWindowController overrides -  because my document is autosaved. 
The application doesn't care at all that the document is "dirty". I know of the 
ApplicationShouldQuit app-delegate call, but I do not want to interfere with 
the Document architecture - I believe there must be a point to introduce my 
document-closing logic. But where?

There's more, but I'll wait for some answers first...


Motti Shneor.
-- ceterum censeo microsoftiem delendam esse ---

___

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