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 738486 - Repeatedly asks to save saved image
Repeatedly asks to save saved image
Status: RESOLVED OBSOLETE
Product: shotwell
Classification: Other
Component: viewer-mode
0.20.x
Other Linux
: Normal normal
: ---
Assigned To: Shotwell Maintainers
Shotwell Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-10-13 21:17 UTC by Tim Waugh
Modified: 2020-12-16 14:07 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Tim Waugh 2014-10-13 21:17:41 UTC
When editing images in Shotwell Viewer, after making a change and choosing File->Save from the menu, the file is not marked as saved (i.e. title bar still shows asterisk). Consequently, closing the window asks whether the changes should be saved or discarded; choosing either 'Save' or 'Close Without Saving' causes the prompt to show for a second time.

Seen in:
shotwell-0.15.1-1.fc20.x86_64
shotwell-0.20.1-1.fc21.x86_64

Original bug report with example image that reproduces the problem consistently:
  https://bugzilla.redhat.com/show_bug.cgi?id=1151751

Steps to Reproduce:
1.From the Files application, double-click on the image to edit
2.In the Shotwell Viewer window, click the Crop button
3.Choose the crop, and click the Crop button to apply it
4.Choose File->Save from the menu bar
5.Close the Shotwell Viewer window

Actual results:
3: Asterisk appears in title bar
4: Asterisk remains in title bar
5: Dialog asks whether to save changes

Expected results:
File->Save should cause the asterisk to disapppear from the title bar, and closing the window after having saved should not present a dialog.
Comment 1 Jens Georg 2016-07-24 18:38:21 UTC
Intersting. This only fails when shotwell is opened through nautilus
Comment 2 Jens Georg 2016-07-24 20:16:42 UTC
In the error case, backing_photo_row.timestamp != row.exposure_time is failing, thus has_alterations() always returns true.
Comment 3 Jens Georg 2016-07-24 20:38:44 UTC
I think this shares some parts of its root cause with 749835 - after saving, the date/time entry disappears and thus is always triggering the test in comment 2
Comment 4 Jens Georg 2020-12-16 14:07:37 UTC
Will be tracked as https://gitlab.gnome.org/GNOME/shotwell/-/issues/302