> 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
> 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. [...]
> 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
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
> 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.
>
>
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
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
> 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
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
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
> 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
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
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:
13 matches
Mail list logo
