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 565973 - Changing the image comment does not mark the image as modified
Changing the image comment does not mark the image as modified
Status: RESOLVED OBSOLETE
Product: GIMP
Classification: Other
Component: General
2.6.3
Other All
: Normal normal
: Future
Assigned To: GIMP Bugs
GIMP Bugs
: 590782 637454 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-12-29 21:37 UTC by Dave Row
Modified: 2018-05-24 12:29 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Dave Row 2008-12-29 21:37:08 UTC
Please describe the problem:
Updates to image comments are not saved when "Save" is selected from the "File" menu.

Steps to reproduce:
1. Open a .png file
2. Select "Image," "Image Properties" (redundant, BTW)
3. Select the "Comment" tab
4. Enter some junk and stuff (or this and that, or whatnot or what-have-you)
5. Click "Close"
6. Attempt to save the file ("File," Save")


Actual results:
Notice that changes are not saved (the status bar at the bottom of the user interface will say "No changes need to be saved").

Expected results:
Because the image comment is part of the image file, I would expect changes to the image comment to cause the file to be flagged as dirty/changed.

Does this happen every time?
Yep

Other information:
Due to GIMP's failure to flag the file as dirty, GIMP allows users to close images w/out prompting to save.  This is why I selected the "Critical / Data Loss" rating of this bug.

Workaround:  "Save As" will forcibly save the image and updated comments over the old image (but the need to do this will likely be oblivious to most users).

Thanx!
Comment 1 Martin Nordholts 2008-12-29 23:30:36 UTC
Hi and thanks for the bug report! Let's look at this for 2.6, should be easy to fix.
Comment 2 Michael Schumacher 2008-12-30 00:29:25 UTC
Setting a more descriptive summary.
Comment 3 Martin Nordholts 2009-01-02 17:37:27 UTC
IMO a data-loss bug is always critical, independent of it is is due to a crash or due to the image dirty flag not being set. Let's raise the severity to at least major.
Comment 4 Sven Neumann 2009-01-02 21:41:21 UTC
As a quick work-around, users can unset the 'trust-dirty-flag' property in gimprc.

The easiest fix for this is to make the change of the image comment undoable. I am not sure if this is the expected behavior, but the only clean way to mark the image as dirty is to push an undo step. But if we just make the image-comment an undoable parasite in gimpimagecommenteditor.c:180, then we need to introduce undo compression for parasite changes. Otherwise you will get an undo step for every character you change in the image comment.

So far we did not consider the comment to be image data. I don't think we should attempt to change this in the stable series. If this is changed at all, then it should be moved to the 2.8 milestone.
Comment 5 Martin Nordholts 2009-01-04 18:36:00 UTC
Let's put it on the 2.8 milestone then.
Comment 6 Michael Schumacher 2009-08-19 10:46:38 UTC
*** Bug 592306 has been marked as a duplicate of this bug. ***
Comment 7 Martin Nordholts 2010-02-17 06:50:29 UTC
This is not a trivial change and with current estimations we will not have time to implement this for 2.8, bumping to milestone Future.
Comment 8 Michael Schumacher 2010-12-17 12:38:11 UTC
*** Bug 637454 has been marked as a duplicate of this bug. ***
Comment 9 Michael Natterer 2011-09-24 14:48:44 UTC
*** Bug 590782 has been marked as a duplicate of this bug. ***
Comment 10 GNOME Infrastructure Team 2018-05-24 12:29:31 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/290.