Re: Bunch of CoreData based NSDocument questions.
Re: Bunch of CoreData based NSDocument questions.
- Subject: Re: Bunch of CoreData based NSDocument questions.
- From: Motti Shneor <email@hidden>
- Date: Tue, 24 Nov 2015 08:34:19 +0200
> On Nov 24, 2015, at 00:14, Quincey Morris <email@hidden> wrote:
>
> On Nov 23, 2015, at 12:50 , Motti Shneor <email@hidden <mailto:email@hidden>> 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 is nearly impossible because it depends on microscope setup and exact positioning of the specimen - outside of the computer.
>
> 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.
My document restores properly, and is alright. But application state is not document state!!! There may be application-level long-term activities outside of the document scope - they may (or may not) produce something persist-able.
I have a UI issue here. My application CAN NOT be thrown away anytime. Being completely restorable is a nice goal - but does not fit any kind of application.
I now have this nasty idea… I’ll disable quitting while this window is onscreen. hmmm….
>
> It’s beginning to sound like autosavesInPlace==NO might be a good starting point for clearing your list of problems.
>
As I wrote above - I tried this, but it has nasty side-effects too.
Motti.
_______________________________________________
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