On Apr 25, 2013, at 10:21 , Kevin Perry wrote:
> Actually no—autosaving-in-place means exactly that changes are always saved
> to the main document file, hence "in place". There is only ever a single file
> per document, even when quitting.
Oops, I obviously got too focused on the "autosave el
On Apr 25, 2013, at 10:05 AM, Quincey Morris
wrote:
>> I can't begin to count the number of times I've opened documents, edited
>> them in some way, not intending to save those changes. Maybe I just needed
>> to, say, find an image in a particular layer of some image editing app, so I
>> hid
On Apr 25, 2013, at 09:10 , Steve Mills wrote:
> Saving in place is not something most users expect, because it hasn't been
> done that way on all the common platforms.
Uh, you can't make statements like that without citing evidence. Have you
surveyed most users on this point? There are plenty
On Apr 25, 2013, at 11:01:08, Jerry Krinock
wrote:
> "PDFpen 6.0.2 is now available from Smile. This update includes an option to
> turn off autosave and versions."
Good. More apps need to offer that ability.
> H. Two bug fixes after Autosave and Versions was adopted with great
> fanfa
On 2013 Apr 24, at 11:38, Steve Mills wrote:
> Like the way TextEdit does it; you see the change take place, but then it
> instantly blinks back to the way it was before. It's *very* un-Mac-like and
> feels extremely half-baked.
On the contrary, I would suspect that it has been fully baked t
On Apr 24, 2013, at 13:29:13, Jerry Krinock
wrote:
> That's maybe not the hardest thing you'll do this week. Add this to your
> code snippets…
>
>if ([self isInViewingMode]) {
>NSBeep() ;
>return ;
>}
>
> and start pasting! My Lion-autosaved app uses that in 34 place
On 2013 Apr 24, at 11:00, Steve Mills wrote:
> but the way Cocoa doesn't prevent things from happening in version browser
> documents added a huge amount to our workload
That's maybe not the hardest thing you'll do this week. Add this to your code
snippets…
if ([self isInViewingMode]) {
On 2013 Apr 24, at 07:58, Steve Mills wrote:
> Could it be because we're not using Cocoa's undo manager or because I have
> preservesVersions and autosavesInPlace turned off?
Yes.
Plus everything that Mike said on this thread today.
As I said yesterday, there are three different autosave mec
On 24 Apr 2013, at 19:00, Steve Mills wrote:
> On Apr 24, 2013, at 12:34:41, Mike Abdullah
> wrote:
>
>> It doesn't surprise me, so much as it confuses me! I thought you'd turned on
>> +autosavesInPlace and were trying to get it not to autosave at certain
>> times. But now you're saying you'
On Apr 24, 2013, at 12:34:41, Mike Abdullah
wrote:
> It doesn't surprise me, so much as it confuses me! I thought you'd turned on
> +autosavesInPlace and were trying to get it not to autosave at certain times.
> But now you're saying you're not using it.
>
> Are you using the old 10.4-based a
On 24 Apr 2013, at 16:12, Steve Mills wrote:
> On Apr 24, 2013, at 10:00:13, Mike Abdullah wrote:
>
>> On 24 Apr 2013, at 15:58, Steve Mills wrote:
>>
>>> Could it be because we're not using Cocoa's undo manager or because I have
>>> preservesVersions and autosavesInPlace turned off?
>>
>>
On Apr 24, 2013, at 10:00:13, Mike Abdullah wrote:
> On 24 Apr 2013, at 15:58, Steve Mills wrote:
>
>> Could it be because we're not using Cocoa's undo manager or because I have
>> preservesVersions and autosavesInPlace turned off?
>
> You do?! That takes us back to an earlier point then, sur
On 24 Apr 2013, at 15:58, Steve Mills wrote:
> Could it be because we're not using Cocoa's undo manager or because I have
> preservesVersions and autosavesInPlace turned off?
You do?! That takes us back to an earlier point then, surely – you're using a
custom autosave system?
__
Could it be because we're not using Cocoa's undo manager or because I have
preservesVersions and autosavesInPlace turned off?
--
Steve Mills
office: 952-818-3871
home: 952-401-6255
cell: 612-803-6157
On Apr 24, 2013, at 09:25:25, Jerry Krinock wrote:
> I agree with all of Mike's warnings, and
I agree with all of Mike's warnings, and continue to be amazed that Steve is
able to sidestep the whole minefield of
-autosaveWithImplicitCancellability:completionHandler: hangs in which so many
of us have lost limbs.
In my Lion-autosaved app, I override
-autosaveWithImplicitCancellability:co
On 24 Apr 2013, at 04:16, Steve Mills wrote:
> On Apr 23, 2013, at 17:39:17, Mike Abdullah
> wrote:
>
>> -hasUnautosavedChanges continues to be applicable to all (auto)saving models.
>>
>> I caution against overriding it since:
>>
>> A) Your override is likely a lie to the system when you ge
On Apr 23, 2013, at 17:39:17, Mike Abdullah
wrote:
> -hasUnautosavedChanges continues to be applicable to all (auto)saving models.
>
> I caution against overriding it since:
>
> A) Your override is likely a lie to the system when you get down to it. This
> might upset the state for other bits
On 23 Apr 2013, at 15:19, Jerry Krinock wrote:
>
> On 2013 Apr 22, at 21:42, Steve Mills wrote:
>
>> [-setAutosavingDelay:0.0] didn't work.
>
> OK, then. I retract my surprise.
>
>> The pause mechanism is something in our own code - a bool that says it's
>> paused (it's actually an integer
On 2013 Apr 23, at 08:18, Steve Mills wrote:
> What do you mean by "not running the show in Lion autosave"? As opposed to
> 10.8 and later, or 10.6 and earlier? (Please use numbers, as it's easier to
> remember the order of numbered versions.)
When I say "Lion Autosave", I mean this feature,
On Apr 23, 2013, at 09:19:47, Jerry Krinock wrote:
> That's fine, but your code is not running the show in Lion autosave. The
> holy grail we're discussing here is a method to tell Cocoa "Stop sending me
> autosave requests (-[NSDocument
> autosaveWithImplicitCancellability:completionHandler
On 2013 Apr 22, at 21:42, Steve Mills wrote:
> [-setAutosavingDelay:0.0] didn't work.
OK, then. I retract my surprise.
> The pause mechanism is something in our own code - a bool that says it's
> paused (it's actually an integer so it can be incremented/decremented in a
> nested fashion).
On 22 Apr 2013, at 23:57, Jerry Krinock wrote:
>
> On 2013 Apr 22, at 09:43, Steve Mills wrote:
>
>> So to sum up, upon pausing autosave
>
> which, per previous messages in this thread, I presume you do by sending the
> shared document controller -setAutosavingDelay:0.0. I'm surprised that
On Apr 22, 2013, at 17:57:41, Jerry Krinock wrote:
> which, per previous messages in this thread, I presume you do by sending the
> shared document controller -setAutosavingDelay:0.0. I'm surprised that this
> has any effect, because this method is "Available in OS X v10.4 and later",
> and i
On 2013 Apr 22, at 09:43, Steve Mills wrote:
> So to sum up, upon pausing autosave
which, per previous messages in this thread, I presume you do by sending the
shared document controller -setAutosavingDelay:0.0. I'm surprised that this
has any effect, because this method is "Available in OS
The out-of-whackishness that I was seeing was caused by our own portable code
which stored the current doc dirty state in a global. AUGH!! Yes, a global. *I*
didn't write it that way. :) Anyhoo, it was preventing the document from ever
being dirtied again. So to sum up, upon pausing autosave I e
On 20 Apr 2013, at 04:17, Steve Mills wrote:
> On Apr 19, 2013, at 16:51:20, Jerry Krinock
> wrote:
>
>> Maybe you Steve and Alex Zavatone may be on to something there. You're
>> suggesting that, rather than handling the autosave when it is requested
>> during a long-winded operation, you t
On 19 Apr 2013, at 21:42, Jerry Krinock wrote:
>
> On 2013 Apr 19, at 12:37, Mike Abdullah wrote:
>
>> Why, what's wrong with cancelling a [auto]save?
>
> That's a damned good question, Mike. You're probably thinking that, hey, we
> lived without any autosaves from 1984 to 2011. What's th
On 19 Apr 2013, at 21:22, Quincey Morris
wrote:
> On Apr 19, 2013, at 13:04 , Steve Mills wrote:
>
> c. If the autosave is asynchronous, you can just not return from it until
> playback finishes. Note, however, this does not prevent another autosave from
> arriving after some time interval,
On 19 Apr 2013, at 21:04, Steve Mills wrote:
> On Apr 19, 2013, at 14:37:11, Mike Abdullah wrote:
>
>> Why, what's wrong with cancelling a save?
>
> It just seems icky. Who knows what behavior this will cause in the future? I
> just tried this approach, and it works the same as when I tried
On Apr 19, 2013, at 5:51 PM, Jerry Krinock wrote:
>
> On 2013 Apr 19, at 13:58, Alex Zavatone wrote:
>
>> "many developer type people would assume that a save of a document's data is
>> a write of a delta of the data to a disk, which would take an amount of time
>> that is so small that it w
On Apr 19, 2013, at 16:52:35, Quincey Morris
wrote:
> You may have covered this ground already and I missed it, but what happens if
> you return NO from the autosave, along with a cancel error (that is,
> domain=NSCocoaErrorDomain code=NSUserCancelledError).
>
> On iOS, the document has a spe
On Apr 19, 2013, at 16:51:20, Jerry Krinock
wrote:
> Maybe you Steve and Alex Zavatone may be on to something there. You're
> suggesting that, rather than handling the autosave when it is requested
> during a long-winded operation, you turn autosave off *before* the
> long-winded operation b
On Apr 19, 2013, at 14:39 , Steve Mills wrote:
> so autosave will happen again during playback
You may have covered this ground already and I missed it, but what happens if
you return NO from the autosave, along with a cancel error (that is,
domain=NSCocoaErrorDomain code=NSUserCancelledError)
On 2013 Apr 19, at 13:58, Alex Zavatone wrote:
> "many developer type people would assume that a save of a document's data is
> a write of a delta of the data to a disk, which would take an amount of time
> that is so small that it would be transparent to the user".
I think this is the model
On Apr 19, 2013, at 15:22:28, Quincey Morris
wrote:
> a. When you get an autosave during playback, can you save the dirty state of
> the document, return a YES result but not actually autosave, then when
> playback stops, if you have this saved state, restore it (via
> NSChangeReadOtherConten
On Apr 19, 2013, at 15:42:05, Jerry Krinock
wrote:
> That's a damned good question, Mike. You're probably thinking that, hey, we
> lived without any autosaves from 1984 to 2011. What's the big deal? It
> turns out that you need to be really careful when playing around with an
> autosave th
On 19 Apr 2013, at 21:42, Jerry Krinock wrote:
>
> On 2013 Apr 19, at 12:37, Mike Abdullah wrote:
>
>> Why, what's wrong with cancelling a [auto]save?
>
> That's a damned good question, Mike. You're probably thinking that, hey, we
> lived without any autosaves from 1984 to 2011. What's th
I think a good way of summing up your statement is "many developer type people
would assume that a save of a document's data is a write of a delta of the data
to a disk, which would take an amount of time that is so small that it would be
transparent to the user".
It's apparent that with your d
On 2013 Apr 19, at 12:37, Mike Abdullah wrote:
> Why, what's wrong with cancelling a [auto]save?
That's a damned good question, Mike. You're probably thinking that, hey, we
lived without any autosaves from 1984 to 2011. What's the big deal? It turns
out that you need to be really careful w
On Apr 19, 2013, at 13:04 , Steve Mills wrote:
> This leads me to believe that the autosave dirty state is getting out of
> whack if the save doesn't happen as planned. Any ideas?
a. When you get an autosave during playback, can you save the dirty state of
the document, return a YES result but
On Apr 19, 2013, at 14:37:11, Mike Abdullah wrote:
> Why, what's wrong with cancelling a save?
It just seems icky. Who knows what behavior this will cause in the future? I
just tried this approach, and it works the same as when I tried returning NO
from hasUnautosavedChanges; it successfully p
On 19 Apr 2013, at 20:17, Steve Mills wrote:
> On Apr 19, 2013, at 13:40:12, Mike Abdullah wrote:
>
>> Why is it causing an interruption? That sounds suspicious to me.
>
> Just because. This isn't simply ol' audio playback. This is a lot more
> complex. Go with it.
OK.
>
>> It sounds like y
On Apr 19, 2013, at 13:40:12, Mike Abdullah wrote:
> Why is it causing an interruption? That sounds suspicious to me.
Just because. This isn't simply ol' audio playback. This is a lot more complex.
Go with it.
> It sounds like you might want to have your -write… routine check
> -autosavingIsI
On 19 Apr 2013, at 19:25, Steve Mills wrote:
> What's the best way to temporarily disable autosave (autosavesInPlace and
> preservesVersions are both off), like if I don't want to interrupt our audio
> playback? Simply override hasUnautosavedChanges and return NO if I want it
> disabled, othe
What's the best way to temporarily disable autosave (autosavesInPlace and
preservesVersions are both off), like if I don't want to interrupt our audio
playback? Simply override hasUnautosavedChanges and return NO if I want it
disabled, otherwise call super?
--
Steve Mills
office: 952-818-3871
45 matches
Mail list logo
