Re: NSDocument disc undo stack
If there's no mechanism to persist the app undo states and undo manager messages, how should apps that support undo work with the automatic termination behaviour ? Should automatic termination be set dynamically and disabled when undo history is present ? A user might be annoyed if the undo history were lost when the app went off screen. "the system may also quit an app with open windows if the app is not currently on screen, perhaps because the user hid it or switched spaces." TextEdit (in 10.7) retains its undo history beyond save, until the document or application is closed. Steven. > > > On 25/03/2012, at 5:34 AM, Doug Clinton wrote: > >> I don't know if this was the issue that Steven was asking about, but I've >> been wondering if there is a recommended way to persist the undo stack so >> that it's still available if you restart the app, or close and re-open the >> document. It's always bothered me that there is this great mechanism for >> handling undo, but that all the history is thrown away when you close the >> app. > > > No easy way I know of. The undo architecture relies on a huge amount of state > within the app external to the undo stack itself. You'd have to save all of > that state somehow. > > In fact, most apps throw away the undo history on a document save (you > arrange this), as a way to recover the memory used by undo, since the whole > state is being saved in the file anyway. Versions are the supported mechanism > for persistent document undo. > > --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: NSDocument disc undo stack
I don't think it's likely to be true in practice on 64-bit systems either. In theory, yes, the old data could get paged out, and will not be paged back in until the user uses it. In practice though, unless these pieces of old data are big, contiguous buffers taking up pages by themselves, the old data will likely live in pages that also contain at least a few things that are at least intermittently used, so you'll be constantly paging. Jamie. On Sunday, 1 April 2012 at 11:42, Mike Abdullah wrote: > I think it's fair to say this is only true for a 64 bit app. In a 32 bit app, > it's fairly easy to exhaust your address space if all deleted files are kept > in-memory. > > On 26 Mar 2012, at 00:57, Steven wrote: > > > Thanks for the info Graham. > > I'm using NSUndoManager. I thought that many large objects in the stack > > would cause memory pressure and would be better occupying disc space as > > they are only needed at undo/redo time. Good to know that the VM system > > will take care of it. > > > > Steven. > > > > On 24 Mar 2012, at 01:04, Graham Cox wrote: > > > > > You can read and write to the Application Support folder. > > > > > > But FILES in an Undo stack? That makes little sense to me. > > > > > > If you want to undo changes to a file, store the changes or the command > > > that will cause the changes in the undo stack. If you are changing the > > > organisation of files on disc then save a description of that > > > organisation in the undo stack. You may want to read up on the way Cocoa > > > utilises Undo, because it sounds like you might not have a good grasp on > > > it. > > > > > > Even if you need to store very large objects in the undo stack, unless > > > you can prove it's a serious problem, just let the memory get paged to > > > disk VM naturally. It's rare that users need to undo a very long history, > > > so even if the older history is paged out, the chances are the user will > > > never know. > > > > > > --Graham > > > > > > > > > > > > > > > > > > On 24/03/2012, at 10:17 AM, Steven wrote: > > > > > > > Hello, > > > > > > > > Where is the correct place to store an on-disc undo stack associated > > > > with a NSDocument instance ? > > > > The stack may contain several potentially large files so we don't want > > > > them to occupy memory. > > > > For a compound document the stack could reside in a directory > > > > NSFileWrapper. > > > > For a single file document should a temporary directory be used ? > > > > I guess the chosen location may need to persist beyond the occurrence > > > > of the automatic termination feature. > > > > Any advice appreciated. > > > > Thanks. > > > > > > > > Steven. > > > > ___ > > > > > > > > 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/graham.cox%40bigpond.com > > > > > > > > This email sent to graham@bigpond.com > > > > ___ > > > > 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/cocoadev%40mikeabdullah.net > > > > This email sent to cocoa...@mikeabdullah.net > > > ___ > > 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/jamie%40montgomerie.net > > This email sent to ja...@montgomerie.net ___ 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: NSDocument disc undo stack
On 25/03/2012, at 5:34 AM, Doug Clinton wrote: > I don't know if this was the issue that Steven was asking about, but I've > been wondering if there is a recommended way to persist the undo stack so > that it's still available if you restart the app, or close and re-open the > document. It's always bothered me that there is this great mechanism for > handling undo, but that all the history is thrown away when you close the app. No easy way I know of. The undo architecture relies on a huge amount of state within the app external to the undo stack itself. You'd have to save all of that state somehow. In fact, most apps throw away the undo history on a document save (you arrange this), as a way to recover the memory used by undo, since the whole state is being saved in the file anyway. Versions are the supported mechanism for persistent document undo. --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: NSDocument disc undo stack
I think it's fair to say this is only true for a 64 bit app. In a 32 bit app, it's fairly easy to exhaust your address space if all deleted files are kept in-memory. On 26 Mar 2012, at 00:57, Steven wrote: > Thanks for the info Graham. > I'm using NSUndoManager. I thought that many large objects in the stack > would cause memory pressure and would be better occupying disc space as they > are only needed at undo/redo time. Good to know that the VM system will take > care of it. > > Steven. > > On 24 Mar 2012, at 01:04, Graham Cox wrote: > >> You can read and write to the Application Support folder. >> >> But FILES in an Undo stack? That makes little sense to me. >> >> If you want to undo changes to a file, store the changes or the command that >> will cause the changes in the undo stack. If you are changing the >> organisation of files on disc then save a description of that organisation >> in the undo stack. You may want to read up on the way Cocoa utilises Undo, >> because it sounds like you might not have a good grasp on it. >> >> Even if you need to store very large objects in the undo stack, unless you >> can prove it's a serious problem, just let the memory get paged to disk VM >> naturally. It's rare that users need to undo a very long history, so even if >> the older history is paged out, the chances are the user will never know. >> >> --Graham >> >> >> >> >> >> On 24/03/2012, at 10:17 AM, Steven wrote: >> >>> Hello, >>> >>> Where is the correct place to store an on-disc undo stack associated with a >>> NSDocument instance ? >>> The stack may contain several potentially large files so we don't want them >>> to occupy memory. >>> For a compound document the stack could reside in a directory NSFileWrapper. >>> For a single file document should a temporary directory be used ? >>> I guess the chosen location may need to persist beyond the occurrence of >>> the automatic termination feature. >>> Any advice appreciated. >>> Thanks. >>> >>> Steven. >>> ___ >>> >>> 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/graham.cox%40bigpond.com >>> >>> This email sent to graham@bigpond.com >> > > ___ > > 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/cocoadev%40mikeabdullah.net > > This email sent to cocoa...@mikeabdullah.net ___ 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: NSDocument disc undo stack
I don't know if this was the issue that Steven was asking about, but I've been wondering if there is a recommended way to persist the undo stack so that it's still available if you restart the app, or close and re-open the document. It's always bothered me that there is this great mechanism for handling undo, but that all the history is thrown away when you close the app. -- Doug On 24 Mar 2012, at 01:04, Graham Cox wrote: > You can read and write to the Application Support folder. > > But FILES in an Undo stack? That makes little sense to me. > > If you want to undo changes to a file, store the changes or the command that > will cause the changes in the undo stack. If you are changing the > organisation of files on disc then save a description of that organisation in > the undo stack. You may want to read up on the way Cocoa utilises Undo, > because it sounds like you might not have a good grasp on it. > > Even if you need to store very large objects in the undo stack, unless you > can prove it's a serious problem, just let the memory get paged to disk VM > naturally. It's rare that users need to undo a very long history, so even if > the older history is paged out, the chances are the user will never know. > > --Graham > > > > > > On 24/03/2012, at 10:17 AM, Steven wrote: > >> Hello, >> >> Where is the correct place to store an on-disc undo stack associated with a >> NSDocument instance ? >> The stack may contain several potentially large files so we don't want them >> to occupy memory. >> For a compound document the stack could reside in a directory NSFileWrapper. >> For a single file document should a temporary directory be used ? >> I guess the chosen location may need to persist beyond the occurrence of the >> automatic termination feature. >> Any advice appreciated. >> Thanks. >> >> Steven. >> ___ >> >> 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/graham.cox%40bigpond.com >> >> This email sent to graham@bigpond.com > > > ___ > > 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/doug%40wiredthing.com > > This email sent to d...@wiredthing.com ___ 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: NSDocument disc undo stack
Thanks for the info Graham. I'm using NSUndoManager. I thought that many large objects in the stack would cause memory pressure and would be better occupying disc space as they are only needed at undo/redo time. Good to know that the VM system will take care of it. Steven. On 24 Mar 2012, at 01:04, Graham Cox wrote: > You can read and write to the Application Support folder. > > But FILES in an Undo stack? That makes little sense to me. > > If you want to undo changes to a file, store the changes or the command that > will cause the changes in the undo stack. If you are changing the > organisation of files on disc then save a description of that organisation in > the undo stack. You may want to read up on the way Cocoa utilises Undo, > because it sounds like you might not have a good grasp on it. > > Even if you need to store very large objects in the undo stack, unless you > can prove it's a serious problem, just let the memory get paged to disk VM > naturally. It's rare that users need to undo a very long history, so even if > the older history is paged out, the chances are the user will never know. > > --Graham > > > > > > On 24/03/2012, at 10:17 AM, Steven wrote: > >> Hello, >> >> Where is the correct place to store an on-disc undo stack associated with a >> NSDocument instance ? >> The stack may contain several potentially large files so we don't want them >> to occupy memory. >> For a compound document the stack could reside in a directory NSFileWrapper. >> For a single file document should a temporary directory be used ? >> I guess the chosen location may need to persist beyond the occurrence of the >> automatic termination feature. >> Any advice appreciated. >> Thanks. >> >> Steven. >> ___ >> >> 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/graham.cox%40bigpond.com >> >> This email sent to graham@bigpond.com > ___ 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: NSDocument disc undo stack
You can read and write to the Application Support folder. But FILES in an Undo stack? That makes little sense to me. If you want to undo changes to a file, store the changes or the command that will cause the changes in the undo stack. If you are changing the organisation of files on disc then save a description of that organisation in the undo stack. You may want to read up on the way Cocoa utilises Undo, because it sounds like you might not have a good grasp on it. Even if you need to store very large objects in the undo stack, unless you can prove it's a serious problem, just let the memory get paged to disk VM naturally. It's rare that users need to undo a very long history, so even if the older history is paged out, the chances are the user will never know. --Graham On 24/03/2012, at 10:17 AM, Steven wrote: > Hello, > > Where is the correct place to store an on-disc undo stack associated with a > NSDocument instance ? > The stack may contain several potentially large files so we don't want them > to occupy memory. > For a compound document the stack could reside in a directory NSFileWrapper. > For a single file document should a temporary directory be used ? > I guess the chosen location may need to persist beyond the occurrence of the > automatic termination feature. > Any advice appreciated. > Thanks. > > Steven. > ___ > > 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/graham.cox%40bigpond.com > > This email sent to graham@bigpond.com ___ 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
NSDocument disc undo stack
Hello, Where is the correct place to store an on-disc undo stack associated with a NSDocument instance ? The stack may contain several potentially large files so we don't want them to occupy memory. For a compound document the stack could reside in a directory NSFileWrapper. For a single file document should a temporary directory be used ? I guess the chosen location may need to persist beyond the occurrence of the automatic termination feature. Any advice appreciated. Thanks. Steven. ___ 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
