After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 154316 - Auto-Save should save a backup copy and be enabled by default.
Auto-Save should save a backup copy and be enabled by default.
Status: RESOLVED DUPLICATE of bug 64637
Product: Gnumeric
Classification: Applications
Component: Main System
git master
Other All
: Normal enhancement
: ---
Assigned To: Jody Goldberg
Jody Goldberg
Depends on:
Blocks:
 
 
Reported: 2004-10-02 18:25 UTC by Thomas M. Hinkle
Modified: 2007-11-06 19:51 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Thomas M. Hinkle 2004-10-02 18:25:37 UTC
Open gnumeric; work for a while; encounter a bug that causes Gnumeric to die
unexpectedly. If you've forgotten to save, you will lose your data (this just
happened to me, destroying several hours of work). 

To me, this seems to violate a core GNOME HIG principle: forgive user mistakes
(http://developer.gnome.org/projects/gup/hig/1.0/usabilityprinciples.html#forgive-the-user)

The best solution within Gnumeric as it currently exists is to enable auto-save
(which I have now done). However, this is not enabled by default, probably
because it makes it possible to accidentally auto-save over old work (which is
also a vioaltion of the forgive-the-user principle).  The way to avoid the
accidental auto-save is to ask to be prompted each time Gnumeric auto-saves, but
this makes auto-save into a constant annoyance and forces the user to choose
between being annoyed and being backed up.

The ideal behavior would be to have an emacs-style backup system: user data is
backed up, but user work is not saved over unless the user explicitly saves.
When starting Gnumeric after a crash, the user should be presented with a dialog
explaining that an auto-saved version of the work exists and offering to recover
lost work (ideally it will show the time difference between the auto-saved
version and the last saved version; better still would be to allow the user to
see the differences between the versions).

I don't know whether to categorize this as a severe bug (since it causes lost
user work), an enhancement (since it is a new features), or an HIG-violation
bug. From google searches, I see that in 2002, there was a patch creating a new
version of auto-save
(http://mail.gnome.org/archives/gnumeric-list/2002-February/msg00057.html). I
don't know why this didn't make it into mainstream code. It seems to me a new
solution to autosave is necessary to bring Gnumeric into HIG compliance.
Comment 1 Morten Welinder 2004-10-03 00:17:54 UTC
You can safely leave the categorization to us.  This is not a HIG issue -- the
thing that causes data loss is the crasher bug.

The old saver could use a large amount of memory -- that was the reason we
turned it off.  With the new sax-saver we might be able to turn this on.

I am guessing that we should just save to a different filename.
Comment 2 Thomas M. Hinkle 2004-10-03 00:24:36 UTC
I think saving to a different filename would be an improvement, even if the
default behavior is still not to have autosave on (although perhaps a better
solution would be to check the file-size and then disable/slow-down autosave
when necessary). And hopefully the new saver will provide a way to turn
auto-save on from the start.

I'll file a bug report if I figure out what it was that crashed Gnumeric in the
first place -- it's hard to track a bug that causes an instant close, since you
can't look at what you've done (I believe the crash had to do with a poorly
formed formula of some kind).

In addition to the comment I referenced, I notice that the comment here
(http://bugzilla.gnome.org/show_bug.cgi?id=64637#c9) repeats what I've mentioned
here -- and the replies suggest some of the reasons autosave has yet to be
implemented (which you've repeated here).
Comment 3 Andreas J. Guelzow 2007-11-06 19:51:12 UTC

*** This bug has been marked as a duplicate of 64637 ***