GNOME Bugzilla – Bug 322243
eog doesn't ask whether to save changes
Last modified: 2009-11-15 20:40:59 UTC
This bug has been opened here: https://bugzilla.ubuntu.com/show_bug.cgi?id=19502 "1. Open an image with eog 2. For example, rotate the image clockwise (to, say, let a vertical photo be upright) 3. Close the window eog just quits, no questions asked. The change has not been saved. What should happen : eog should ask the user whether to save changes, or maybe even save changes automatically (in the case of rotating images, I think it would be natural ?). I am running an up-to-date breezy. eog 2.12.1-0ubuntu2"
Confirming. EOG should ask the user whether to save changes before closing.
Created attachment 80799 [details] [review] patch for eog-ng branch This patch shows a dialog asking the user to save changes, confirm quiting, or cancel quitting for every image with unsaved modifications. As in eog-ng saving is still not implemented, the patch won't actually save when hitting the "save" button. I'll mark this bug as depending on bug #377123.
Please don’t show a window asking for this. I had this often before and it is annoying. As Sebastien already mentioned it is natural to just save the file immediately. Imagine, you a resitting in your kitchen with family and just opened your camera to show the new pictures full-screen and rectifying the odd portrait photo always leads to a dialog[1]. How disruptive is that? When you want to rotate the image it is because it was wrongly oriented before, it permanent. And even better it’s lossless (even JPEG, right?). You can go back faster by rotating backwards than saving under a different name and finding the old version.[2] Please just save, thank you. [1] We assume no orientation available sensor in the cam [2] And when we figure the file is read-only, THEN we can show a dialog.
What you describe is more related to bug #338138. You can comment there if you want. This is a bit more general bug report, about changes in the image. If any other changes happen to the image (exif manipulation, or whatever, if added at some stage) this is still needed. Although there's room for improvement. If you want to test the patch and give some comments about the way it works, I'll appreciate it.
I think EOG should ask to save on exit or when the user tries to change the current image. A save button on the toolbar will avoid to see the save dialog often
*** Bug 491092 has been marked as a duplicate of this bug. ***
So what is the direction EOG will go in? Dialogue after every change? Dialogue before closing to save ALL changes? Or "What You See Is What's On Disk" where as soon as you rotate the image, the image on disk is also rotated?
Created attachment 102631 [details] [review] patch updated for trunk This is the same patch as previous one, but with a few improvements and for trunk. Still not functional, but still waiting for comments.
There's also the gedit approach: A single dialog that lists all the images with unsaved modifications and allows you to select, in a gtktreeview, which images to save. I think it's more user friendly than poping up n dialogs for n images.
Could be related to bug 338138
"There's also the gedit approach: A single dialog that lists all the images with unsaved modifications and allows you to select, in a gtktreeview, which images to save. I think it's more user friendly than poping up n dialogs for n images." I believe this is the way to go as well. The user may rotate 20 photos, but then when exiting, it should ask if they would like to "Save all modifications". They select 'yes', EOG does its thing, and the user is now happy that their photos are rotated.
The current behavior is the same as 3 years ago. Silently discarding the user's work, his modifications is the worst method. I would support saving the image at once after a lossless(!) rotation. The approach to ask the user on closing eog if he wants to save all rotations can be a compromise.
I'm agree with Brett (comment #11)
Should this be re-targeted for 2.28? Claudio, any work on the patch recently? I bet a lot of users would very much appreciate this :)
(In reply to comment #14) > Should this be re-targeted for 2.28? Claudio, any work on the patch recently? I > bet a lot of users would very much appreciate this :) > Not really. Feel free to take over.
Created attachment 141392 [details] Screenshot of gedit showing a warning I'm not sure this save all dialog would be the best thing todo as it can be difficult to which image to save and what not in a list (even with thumbnail) and often you have a quite long "image view session" where you could have viewed and rotated perhaps hundreds of images. I would instead suggest having a bar similar to gedit (when file on disk has changed, see attached screenshot). It would then be more obvious you have changed the file and the application notifies you about it and lets you save it with a single click. Suggested buttons would be "Save" and "Save as" or "Restore". What do you think?
I just used Vista image viewer the other day and this is how it works: You open a photo, rotate it and click next and then it saves the image and shows the next photo. I think we could improve that operation by showing the next photo while the last one was saving and then not allowing eog to quit until all saving operations were complete. Either way, I think that's the route we should go with.
Please only save automatically, if it's indeed lossless (only metadata changed). If the JPEG itself is altered when rotating (which would be lossy), saving automatically would be a several bug IMHO (this is an image *viewer*, and I don't expect it to alter my files, much less in a damaging way, just because I wanted to *view* them rotated).
OK, I just tried to rotate a JPEG image of mine and save it in eog. The result: it sure does mess with the data, the size before was 360KB and the rotated image got a size of 423KB. So until eog gets lossless (or nonadding?) save support I'd suggest adding a GtkInfoBar informing the user it has changed the image and it could be saved (maybe with a warning). I could give this a try if any of the devs could decide if this is the way to go.
The GtkInfobar approach is nice, but has some problems: - If it comes up automatically upon changing an image, it will likely start to annoy users soon. - What if I change multiple images at once? - What if I change images in Fullscreen/Slideshow mode? I prefer a "catch-all" dialog that pops up when the active window is closed, and offers me a list of changed images and asks me to save the images. It stays out of my way until I'm done with all my changes, catches the accidential double-ESC in fullscreen, and of course works with many changed images. Further niceties would be to make it deactivatable in the preferences and show a little thumbnail for each image in the dialog's list. @Ben: Regarding autosaving, see bug 338138. *Resetting status as Claudio has currently no time to work on this as mentioned in comment 15 *
Created attachment 143942 [details] Screenshot showing work in progress Just a note; I've started working on this.
Looks nice so far. :-) You can write "images" instead of "documents".
Felix, definitely, but i stole the dialog from gedit and haven't changed the text yet :-)
Hmm, ideally, saving should happen automatically in most of the cases. We don't really deal with images on the same way than documents. Usually, we deal with many more images at once than documents. So, in the normal case, you don't really want to care to save images. Except when you're dealing with more complex image editing or the transformation is not lossless. So, I think the confirmation dialog should be used only in cases where's it's not 100% safe to do the right thing: auto-saving the image after transformation.
> saving should happen automatically in most of the cases No, please see comment 18. Often, I only rotate images just to see a lying face, so I don't want that to be saved.
Created attachment 144076 [details] [review] Adds a confirmation dialog on exit when there's unsaved images Dialog based on the dialog from gedit. Seems to work quite well. Not sure what the size of the thumbnails in the list should be, atm it's hardcoded to 20. Comments?
Created attachment 144077 [details] Screenshot of confirm save dialog
Hmm. Just found out that eog has a disable save mode. What would be the best to do if that is activated - don't show the dialog at all or show it with a message that changes will be lost?
Where is the frame around the thumbnail coming from? It looks a bit odd to me.
Claudio, nothing I've put there ;) Actually I think it's my theme that puts the border between the cells in the list. I've got the same border in other lists as well. Btw, did you take a look at the patch?
Just gave it a quick test-run on my laptop. Feels pretty good already. The main window should be better made disabled during saving to avoid user interference during saving. There should be some code available already for this in EogWindow. The thumbnail is really small with my resolution (1400x1050), not sure about smaller resolutions though (Netbooks?). I don't think we need the dialog in the public/plugin API (place the header in the NOINST section of the Makefile). Lucas, autosaving has multiple pitfalls, see bug 338138 for the lengthy discussion about this.
Felix, about the image size; I'm not sure what the best size would be or if it should be dynamic to the font size? Any suggestions? I'll fix the other things.
Well, for now we could make it larger, 20px height is smaller than an icon in the gnome menu. 32px or 40px should be an improvement already. If that still doesn't work out, we can look into other possibilities (dynamic scaling, tooltips,?).
Created attachment 144626 [details] [review] Updated patch Changelog * Move eog-close-confirmation-dialog.h to NOINST * Change thumbnail size to 40px * Don't ask to save if save is disabled Felix, Actually the my main window is pretty locked (can resize window - nothing more) while the dialog is shown. Probably because the dialog is modal (?) - isn't this enough? (Also couldn't find anything about locking/disabled/.. in eog-window)
Created attachment 144627 [details] Updated screenshot with 40px height
(In reply to comment #34) > Felix, Actually the my main window is pretty locked (can resize window - > nothing more) while the dialog is shown. Probably because the dialog is modal > (?) - isn't this enough? (Also couldn't find anything about locking/disabled/.. > in eog-window) Yes, but what I meant is the situation when you click "Save Changes" and eog starts saving. The dialog is gone then and I could use the window as usual (assuming saving takes long enough).
Ahh - of course. Do you know were to look for the code that disables the gui?
Hmm, looks like there's no function in eog you could directly use. The update_ui_visibility function in EogWindow can give you an example on how it might work. Although, simply making the whole window insensitive using gtk_widget_set_sensitive could be enough as well.
Committed your latest patch with some fixes and extensions. Thanks, Marcus! The only(?) thing missing right now is the GConf part. But it should no problem adding that later. Regarding the locking of the main window, I simply lock the whole window and keep the dialog atop of it. commit 295675deeaf0506c38190e9d4e8f95ece9cf0f8f Author: Felix Riemann <> Date: Sun Nov 15 21:18:11 2009 +0100 Keep the dialog alive during saving to lock the main window Make both window and dialog insensitive to avoid any further change to the images during longer save operations. commit 90f583ced89d53c851edd29acf6316c96fb8d660 Author: Felix Riemann <> Date: Sun Nov 15 21:03:44 2009 +0100 Reword save confirm dialog and hook it into intltool Makes the secondary labels sound a bit less dramatic. commit b53f8c99ea0a3265e746a0711449dd8b2720170b Author: Felix Riemann <> Date: Sun Nov 15 20:52:39 2009 +0100 Update copyright year in the save confirmation dialog sources commit c7e758832bc1db897c01cce32e04735c01b879ae Author: Marcus Carlson <> Date: Sun Nov 15 20:50:11 2009 +0100 Add dialog asking whether to save changes on exit The dialog used is based on the one used by gedit. It allows to decide for every changed image. Fixes bgo#322243. 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.
Thanks! I've been quite busy with other stuff the last weeks (or months) so I didn't get the time to update the patch - so thanks for doing that :)