It'd be nice...

[jfoster]

Just got power back after an 5-day Isaias outage. I know where to look for the autosaved workspace file, however it'd be nice if PWP kept tabs on graceful shutdowns and offered to automatically open the autosaved workspace file if the previous shutdown was problematic.

Common feature with other software.

Jeff

[jsachs]

Thanks for the suggestions -- should be doable.

[jfoster]

I don't usually edit photos on my laptop - only when I travel, which is curtailed of late. However, for no particularly good reason I just updated the laptop to the 8.0.130 release from 8.0.62.

A couple things to note.

I first opened (and then closed) an image from the history list (to see what picture I was working on back in March). Then I opened the Workspace for that image and PWP crashed.

When I opened PWP again, it asked if I wanted to open last autosaved workspace. Clicking Yes caused the workspace of the image that I had previously opened, and deliberately closed, to be loaded. IMO this is missing the mark a bit. (I wasn't clear in my suggestion in the above post.) The potential value of prompting to load the last autosaved workspace occurs when a workspace that has not been committed by the user to disk at the time of an ungraceful application shutdown.

With regard to the crash of the 8.0.62 workspace in 8.0.130 release, are there known incompatibilities? Do you want to look at the workspace file?

Jeff

[jsachs]

Yes, please send me the old workspace file. I try to stay upward compatible with old scripts.

Autosaved snapshots are only save when you click OK on a transformation or copy, or close transformations. Normally, a crash will occur after one of these events and the workspace will be restored to that point. If PWP crashes on startup (which should not happen), the last autosave is from the previous workspace.

[jfoster]

I guess I’m not being clear. In the case I just described, I’d expect PWP to not offer to load the autosaved workspace since it doesn’t provide any value to the user. Let me elaborate on what seems to be the algorithm on other software with which I’m familiar.

This feature IMO should NOT merely offer to load the autosaved workspace when there was a previous unexpected application termination, but rather offer to load the autosaved workspace when there was a previous app crash AND the autosaved workspace is in a state where the user has not deliberately committed the changes in the autosaved workspace.

A design approach that may satisfy this logic might be to implement a dirty-bit for the autosave workspace file. Anytime the autosave occurs, as a consequence of a user change to the workspace, this bit is set. When a user merely opens an existing workspace or one image file this bit is not set since no changes have yet occurred.

Any time the user deliberately saves the workspace file OR deliberately closes/aborts the workspace, then the dirty-bit is cleared. The set dirty-bit indicates that the user has not yet committed changes to the workspace file. Now if PWP starts and finds a problematic last shutdown, PWP can check the autosave workspace dirty-bit to see if the file is in a state where it is of value to offer the user the opportunity to open the last autosaved workspace because it contains changes that were made prior to the last deliberate user save/cancel action.

Anyway, the current implementation is probably better than before as at least the user gets a chance to decide whether the autosave file is useful.

Attached is the 8.0.62 workspace file that crashes 8.0.130

Jeff

[jsachs]

Fixed crash recovery for next release.

The script crash was caused by a bug I introduced recently when adding support for 16-bit masks. Also fixed for next release.