GNOME Bugzilla – Bug 491092
eog shouldn't quit while an image is being saved
Last modified: 2008-01-01 00:03:23 UTC
Please describe the problem: When you quit eog while saving a picture, the picture could end messed up. Steps to reproduce: 1. open a big picture 2. make a modification 3. save it 4. close eog while the save progress bar is progessing in the bottom-right. Actual results: eog is closed and your picture is only half-saved hence you lost the original one. Expected results: eog should display a popup window asking to wait before the image is saved. Does this happen every time? yes Other information: What would be better is to have the "save operation" being atomic. Right now, even with a popup window, if eog is killed for whatever reason, the picture would still be half-saved.
The original bug report was opened here: https://bugs.launchpad.net/eog/+bug/155089
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of 322243 ***
That's not the same bug. It's not about warning the user about that changes was made. It's about waiting that an image is properly saved before quitting.
I think my last sentence was not clear enough: When an image is being saved, eog shouldn't be allowed to quit otherwise it could lead to a half-saved image.
More than asking for a confirmation, EOG should check whether the saving jobs queue (and probably others) has pending jobs, and in case there are some, wait until all of them finish before quiting.
Why not, I thought it would be weird to click on the X button without any response from the application.
(In reply to comment #6) > Why not, I think it may be confusing to display a dialog that most of the times would only be visible for, say, half a second or less. And the point of the confirmation is not really clear to me. What would it be the alternative to wait? Quit anyway and leave the image half saved? I don't think so. > I thought it would be weird to click on the X button without any > response from the application. We could set the eog window to be insensitive before closing it. Evolution does this when it needs to synchronize with mail servers before quiting, or when it has pending tasks.
> I think it may be confusing to display a dialog that most of the times would > only be visible for, say, half a second or less. Hmm that might be a problem indeed > And the point of the confirmation is not really clear to me. What would it be > the alternative to wait? Quit anyway and leave the image half saved? I don't > think so. Yes you're right. As long as the move operation is not atomic, it's not possible to let the user have a choice other than waiting. BTW, is this possible to have the last move operation being atomic ? I wonder how other application handle this case, the temporary image would have to be created on the same filesystem and not in /tmp. > We could set the eog window to be insensitive before closing it. Evolution does > this when it needs to synchronize with mail servers before quiting, or when it > has pending tasks. Yes that might be a a good idea. I think what is important is that the user understand that something need to be finished before eog quits. With the insensitive window, the user should see in the bottom bar that an image is being saved and see the progress bar ... progressing. To me, that's enough, but I am not usability expert. Does Gnome HIG say something about this kind of behaviour ?
*** Bug 506263 has been marked as a duplicate of this bug. ***
Created attachment 101925 [details] [review] Set window unsensitive while saving before closing the window I'm committing this patch in both gnome-2-20 and trunk. When closing a window, this will make it insensitive as long as there is a saving job unfinished, and then will destroy it. The user is still notified that there is a job currently in progress by means of the statusbar. The signal handler disconnection in is done to avoid some critical warnings that appear when the signal is emitted after the window is destroyed.
Committed revisions 4273 (trunk) and 4274 (gnome-2-20). This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report.