GNOME Bugzilla – Bug 451889
Implement auto-save feature
Last modified: 2018-06-29 21:40:54 UTC
We've been asked every other month to offer "auto-save" for the file backend. Eventually after reading "The Design of Everyday Things" it occurred to me we simply have to offer something like that - people expect it, so it whould be there. Also, technically it isn't at all hard to do it. So there we go.
Created attachment 90803 [details] [review] Initial proposal for implementing auto-save That's how this could be working. So far the gconf key lookup for the time interval is still missing (which should offer one-minute granularity, where Zero means autosave is switched off). But the principle is already there. (Untested, though.)
Just want to add that this is not suitable for 2.2.x, because it may destabilize the system and greatly changes user experience. Keep it up, Christian :-)
"destabilize" the system, häh? Whatever. I agree this cannot be included in 2.2.0 unless there has been considerable testing, which is not available in the current schedule. For some later 2.2.x, however, I don't see what would speak against it.
Created attachment 90848 [details] [review] 2nd try for auto-save This is basically the full auto-save feature. Only the preference for the time interval needs to be added. Actually this feature could alternatively still be added for 2.2.0 and used for prominent marketing of the new release. "More user-friendly than ever" etc.
Created attachment 90853 [details] [review] Even more complete implementation Now this code is pretty much completed. The preferences are handled correctly, and book closing is handled, too. I'd even go as far as considering this indeed for 2.2.0.
WRT comment 2: s/the system/gnucash/ Well, I have not taken a look at your patch yet. If you think it is great, then maybe it is :-D But I did not read any recent discussion of this type of request and this implementation, so my instinctive feeling tells me that this change would be too late in the 2.2 release cycle. Maybe I missing the scope of this patch. Is this really a trivial issue? Say, an import process is taking a few minutes, spawning a main loop to update a progress bar. Can that loop call gnc_file_save()? Just call me pessimistic :-)
*** Bug 107365 has been marked as a duplicate of this bug. ***
Created attachment 90869 [details] [review] And add yet more special-case handling Added checking gnc_file_save_in_progress() before initiating our own filesave.
Consider that some operations could take a very long time on slow systems. - Saving the data file last at least 10 seconds, but could be more than one minute if my computer were worst. Autosave shouldn't interfere with normal save. - Generating a report could be a very long (about 5 minutes) operation. We have to see what gnucash is going to do if autosave trigger during a report generation. Autosave must be a feature that doesn't interfere with normal work: my 10 seconds saving should be done enterely in the background, so that it doesn't prevent me entering the txn.
(In reply to comment #9) > Autosave must be a feature that doesn't interfere with normal work: With all due respect, but no, it must not "be a feature that does xyz". The point is: currently we don't have any auto-save at all. What kind of auto-save feature is an improvement from hereon? Something "entirely in the background" is almost impossible to do with the current engine structure, because the current XML backend requires the book to be unchanged *during* saving. Which, of course, is a contradiction to "saving happening in the background". Would the auto-save that we currently have here already be an improvement for a majority of users? If yes, then we offer it. If no, well, then we won't have any auto-save for many more versions and years to come.
Created attachment 90886 [details] [review] This actually works This patch has been tested. Albeit only on a small file, but it works surprisingly well. I'd indeed go as far as suggest it for 2.1.5. Please test it as well. THanks.
What about KEY_AUTOSAVE_SHOWED_EXPLANATION so that FALSE can be the default? I will give it a try. We really need a mail to gnucash-{devel,user} so that others participate with testing though.
(In reply to comment #12) > What about KEY_AUTOSAVE_SHOWED_EXPLANATION so that FALSE can be the default? What's the implications of having FALSE the default? I wanted a key that is FALSE during normal operation, and TRUE only at the beginning but it will be set to FALSE after the first run. That's why FALSE as the value for the normal operation seemed more suitable to me, with TRUE being the default as specified in the schemas file.
Well, I think we decided to try to have FALSE as default, so that missing / unset keys will match default behavior. Oh, and with default I mean "user starts GnuCash for the first time", not "normal operation" here. That is why we chose dev/allow_file_incompatibility. But hey, I added general/show_splash_screen... BTW, there is no "Ok" button :-)
Created attachment 90895 [details] [review] This works indeed With yet another sanity check I tested this with my large normal data file, and there don't seem to occur any problems.
However, during the auto-save the UI isn't turned inactive, and also the progress bar doesn't seem to show the progress of saving. I'm a bit at a loss as to which call would be required in addition to gnc_file_save().
Created attachment 90922 [details] [review] Now we have everything. There we are. It works and correctly switches the UI to inactive. I'd propose to commit to trunk.
Committed as r16226 (that was attachment#90895 [details]) and r16227 (which contains the changes to attachment#90992 [details]). I'm quite confident this feature is at least ready for beta-testing. For the record: When the auto-save triggers during a long calculation of a report, the saving is finished first, but the report calculation continues just fine. The only problem here is that the visual feedback of report calculation (the progress bar) is overridden by the saving and not restored; in other words, the user doesn't see that the report calculation is continuing just fine. Once the report calculation finished, the report is displayed just normal.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=451889. Please update any external references or bookmarks.