GNOME Bugzilla – Bug 64637
Auto save issues
Last modified: 2009-04-30 16:02:13 UTC
If I set the "auto save" setting it is neither kept as a workbook attribute nor as an application setting. 1) new gnumeric 2) A1 gets "hello" 3) Tools -> Auto Save -> check the box, set to 8 minutes, check "Prompt..." 4) Save workbook 5) exit gnumeric 6) new gnumeric 7) re-open the saved workbook --> A1 should be "hello". The "auto save" settings are lost. cheers, adrian
Created attachment 6294 [details] [review] workbook-control-gui.c.diff - Use gnome_config to remember settings
The above patch will remember the setting on a global basis. I think this is better than per a document setting. Please commit and make me happy.
Sorry, gnome_config is the wrong way to go for this. Please make it a workbook attribute.
Jody can you give a reason? In XL it is app wide (apparently). If the user is fearful that the wrong doc will be autosaved then they will have set the 'prompt for confirmation' option. I had actually asked you on IRC which way you wanted it, but I don't think you answered. As a user, if I liked this feature, then I would be very annoyed to have to turn it on for every gnumeric document I have. (given that the default is OFF)
Ok Adrian showed me in irc, you did tell me to do it workbook based. I should have listened more carefully. But any particular reason why?
One reason: I may have some files open from locations I can't write to (either because the medium is read only or just because of permissions). That should not imply that I can't set autosave for some files. Of course ideally I would think we have a user specific preference which applies to all files and can be overwritten on an individual basis.
I thought that it would be quite trivial to save the autosave settings with a workbook. It appears not to be since the autosave settings are not unquely attached to a workbook. If you open 2 views of a workbook, you can have one set to autosave while the other does not. The autosave settings appear to be attached to the WorkbookControlGui rather than to the workbook.Saving is of course implemented on the level of workbook. Given a single workbook we could have multiple WorkbookControlGUIs attached to it. How do we know which ControlGUIs settings are supposed to use?
*** Bug 69091 has been marked as a duplicate of this bug. ***
Personally, I think the current autosave implementation is just the Wrong Way to do things. Gnumeric should use an emacs-like system where a backup file is saved regularly (to /tmp, or the local dir, or somewhere similar) w/o the user ever being aware of it. This temporary backup is removed whenever a 'real' save is done and the file is no longer dirty. On startup, gnumeric should check for the presence of the autosave file and offer to restore it if appropriate. [For clarity, this is the (non-permanent) "#foo" emacs backup file I'm referring to here, not the "foo~" backup which persists. The 'xcircuit' drafting program contains another implementation of this idea; I'm sure there are others, too.] This way, it is *never* wrong to auto-save --- we write our backups to writable storage even if the original was read-only --- and the preference can completely go away. You'll never notice gnumeric watching your back until you need it, and then the salvation is miraculously provided. I will code this eventually if no one beats me to it. I hate to see the effort wasted on a fundamentally wrong approach.
I agree whole heartedly. The current scheme does not work well in the context of multiple views. A proper journaled backup system akin to vim should be feasbile with the current architecture (some extensions to src/commands.c should be enough). This would be an excellent project if you are interested.
> This way, it is *never* wrong to auto-save Actually, it is. We currently use way too much memory during save and are in danger of running out of memory there. Auto-save under this scheme could cause crashes.
jody: if you want to use the undo framework to do autosave, you need to figure out what to do with removing/adding/renaming sheets.
renaming, adding and deleting sheets should be undoable anyways. But we also have to make all the analysis tools undoable etc. (Which they should be anyways too.)
Comment on attachment 6294 [details] [review] workbook-control-gui.c.diff - Use gnome_config to remember settings Marking obsolete based on comments later in the bug. (Just going through and cleaning up some old patches all over bugzilla, mostly safe to ignore me.)
Comment on attachment 6294 [details] [review] workbook-control-gui.c.diff - Use gnome_config to remember settings Should have said needs-work.
*** Bug 154316 has been marked as a duplicate of this bug. ***
*** Bug 543223 has been marked as a duplicate of this bug. ***
I use gnumeric in most simple way: I open a file from my disk in single view and write something to it. I have trusted gnumeric to have small footprint and will be fast to load and easy to use, but... I have lost day of work becasue of this bug altogether, simply by forgetting to save before logging off: * First I did not find auto-save option in preferences. It should be there as application global option. I believe this covers most of use-cases, thus kills the 90% of bug. For other cases you should have own special (overriding?) settings elsewhere. * I have found auto-save under Tools. First, it is non-intuitive location. Second, it is not persistent nor warns you that is not persistent. It should be persistent to something (workbook or application) or should at least warn user. * Loosing data is one of most annoying thing it can happend and fact that can happen so easily with gnumeric means that it is still immature. It should have make backup saves or backup file regardless of the auto-save. Please just add auto-save in preferences as application wide setting and 90% of problems will be solved.
In the current development version you can set the default autosave time. If it isn't 0, it will (by default) prompt you to save your file. So 90% of your problems should already be solved.
I guess this enhancement request should be considered fixed. This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.