I've filed this bug before but am surprised to see it still in version 3.

While APP/APG 3.0 have been quite stable, I got my first core dump today.  There were no diagnostics, alas.  I was editing a 3row 24 column 360 pano with 2 extra images inserted, and during layer editing to remove some redundant images, it started sucking up all CPU (even to mouse slow down) and I let it stew unresponsive for a few minutes when it dumped core and terminated.

However, I doubt you can do much from that bug report, but the real bug report is that after the crash, all my work was lost.  All changed settings in APG were forgotten (I had to re-enter registration key even) -- these had been entered at the beginning of the session, it was the first session.  In addition, the workspaces were lost, and this particular pano, which had not been saved, was lost, including all my control point edits.

Almost every other program I have used in the last several years doesn't do this -- they all periodically save their intermediate state every few seconds to a disk file in the spool, and when they restart after a crash, if they see that file lying around, they do a crash recovery from it so that the user loses no work.   That users can't lose work is a very fundamental feature of a robust program -- all programs will have occasional crashes, so you must assume they will happen and assure work is not lost.

Because APG does not do this I try to save from time to time manually but that's not really a good workaround.  In addition, often I am doing experimental changes and don't want to save, and creating new files for each experiment and then renaming back to the original is cumbersome.

I know that APG can save the workspace and of course it can save the current state of the pano file,  so I don't see this is a lot of code.

a) Every so often, during idle periods in user interaction, save the workspace and any unsaved panos into a spool directory with a magic filename.
b) Delete the magic file if the pano is manually saved by the user, and delete the magic file on quit or discard.
c) If, on startup the magic files are there, presume a crash and ask the user if they would like to do crash recovery.

Settings changes should be saved on change, not on quit, even if they don't take effect until the next run of the program.


I can't be the only one to lose work to a crash.