Re: Bunch of CoreData based NSDocument questions.

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

Re: Bunch of CoreData based NSDocument questions.

(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 d

Re: Bunch of CoreData based NSDocument questions.

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:

Re: Bunch of CoreData based NSDocument questions.

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 totall

Re: Bunch of CoreData based NSDocument questions.

> 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 av

Re: Bunch of CoreData based NSDocument questions.

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 sa

Re: Bunch of CoreData based NSDocument questions.

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 do

Re: Bunch of CoreData based NSDocument questions.

> 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 c

Re: Bunch of CoreData based NSDocument questions.

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 y

Re: Bunch of CoreData based NSDocument questions.

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 data

Re: Bunch of CoreData based NSDocument questions.

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

Re: Bunch of CoreData based NSDocument questions.

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 im

Re: Bunch of CoreData based NSDocument questions.

> 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 on

Re: Bunch of CoreData based NSDocument questions.

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

Re: Bunch of CoreData based NSDocument questions.

> 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

Re: Bunch of CoreData based NSDocument questions.

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 “mod

Re: Bunch of CoreData based NSDocument questions.

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

Re: Bunch of CoreData based NSDocument questions.

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 au

Re: Bunch of CoreData based NSDocument questions.

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 abo

Re: Bunch of CoreData based NSDocument questions.

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 autosavi

Re: Bunch of CoreData based NSDocument questions.

> 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

Re: Bunch of CoreData based NSDocument questions.

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 m

Re: Bunch of CoreData based NSDocument questions.

> 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

Re: Bunch of CoreData based NSDocument questions.

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 immedia

Re: Bunch of CoreData based NSDocument questions.

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-

Re: Bunch of CoreData based NSDocument questions.

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

Re: Bunch of CoreData based NSDocument questions.

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 m

Bunch of CoreData based NSDocument questions.

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 wa