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 98485 - Default comment should not be set before saving
Default comment should not be set before saving
Status: VERIFIED WONTFIX
Product: GIMP
Classification: Other
Component: General
1.x
Other All
: Normal minor
: ---
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2002-11-14 14:59 UTC by Raphaël Quinet
Modified: 2009-08-15 18:40 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Raphaël Quinet 2002-11-14 14:59:26 UTC
Contrary to what is written in bug #51164, I think that the default comment
should not be set automatically when creating a new image (File->New or
Acquire->Screenshot or Edit->Paste as New).  It should be non-existant or
empty until the file is saved.

With the way it is currently done, the comment is set when the image is
created (although the user does not see that).  So if the user creates
several new images or screenshots, goes to the preferences to change the
default image comment, creates more images and then saves them, this would
result in some images having the old comment and some of them having the
new one.  The user does not have the opportunity to see what comment is
attached to what image until they are saved.  So it would make more sense
to attach the comment when the image is saved, not before.  This behavior
would be more consistent from the user's point of view.

I suggest to fix this usability bug in the following way:
* Do not attach a default comment to new images.
* All file plug-ins should check if the gimp-comment parasite is attached
  to the image that they are about to save.  If not, then they should get
  the default from the preferences and attach that to the image.
* If possible, all file plug-ins that are interactive should display the
  current comment and allow the user to modify it or to replace it with
  the current value of the default comment (as suggested in bug #51164).
  Alternatively, this ability to view and edit the comments could be
  removed from all file plug-ins if a comment editor is implemented (see
  bug #61499).

The second step (copy the comment from the preferences if it is not set)
could be wrapped into a new libgimp function if we want to make it easy
for plug-in developers.
Comment 1 Dave Neary 2003-05-13 07:07:57 UTC
Fixed in 1.2: 
2003-05-12  Dave Neary  <bolsh@gimp.org>

        * plug-ins/common/csource.c
        * plug-ins/common/jpeg.c
        * plug-ins/common/tiff.c: If no comment is set on a
        GimpImage when it arrives to be saved, don't attach one.
        Fixes bug #98490 and bug #98485

        * plug-ins/common/tiff.c: Alert user to loss of precision
        when opening a 16 bit tiff. Backport of Maurits Rijk's
        fix for bug #95737

Comment 2 Dave Neary 2003-05-13 08:56:31 UTC
Ooops - that'll teach me to not read things properly.

I disagree with Raphael here. I believe that it's up to the GIMP core
to set the comment default when creating the images. If an image
created with an application other than the gimp contains no comment,
that image is indistinguishable from an image created by the gimp once
we get to the save routines in the plug-ins. In this case, no comment
should be attached by default. 

The alternative is to add a flag to GimpImage indicating that an image
was greated by the gimp, and attaching the default parasite in the
core while saving, and before we hand control to the plug-in. Or to
read the preference file in every plug-in. But that seems messy to me.
Adding a boolean flag to say "I made this" just doesn't seem right.

Cheers,
Dave.
Comment 3 Raphaël Quinet 2003-05-14 08:58:18 UTC
As I wrote in the second paragrap of the original description, this is
a usability problem for the user who does not (and should not) know
how image comments are handled internally.  The user does not see the
comment until the image is saved.  Changing the default comment does
work as expected.

The problem may become irrelevant in the 1.3.x branch if we add a
comment editor as described in bug #61499 because the user will then
have an easy way to view and edit the comment (and other metadata) at
any time.

But this will not work for the 1.2 branch because it is unlikely that
we will add a metadata editor in this branch (the current parasite
editor does not count for obvious reasons).  So I think that the
correct way to solve this problem in the 1.2 branch is to ensure that
the default comment is attached to the image when it is saved, not
before.

I don't think that it would be a problem to attach the default comment
to the images that were originally loaded from a file that had no
comment.  But if you would like to avoid this, then I propose the
following solution:
- All images created by the GIMP core are created _without_ the
  gimp-comment parasite.
- All plug-ins creating new images from scratch (e.g., various
  scripts, xsane, screenshot, etc.) create their images _without_ the
  gimp-comment parasite.
- All plug-ins loading images from a file create their images _with_
  a gimp-comment parasite.  If there was no comment in the file or if
  the file format does not support comments, then the parasite is
  attached as an empty string.
- All plug-ins saving images to a file (in a file format supporting
  comments) check if the image has a gimp-comment parasite attached to
  it.  If there is one (including an empty one), then it is saved to
  the file.  If there is no parasite, then the default comment is
  used.

This should lead to a more consistent behavior.
Comment 4 Dave Neary 2003-05-14 09:47:56 UTC
That's a considerably bigger change that the one needed to close this
bug. I propose opening a new bug which details the behaviour you
outline here. I think that plugging the holes one at a time (as has
been done here for screenshot and for paste as new) is reasonable
until someone addresses the issue in the way you suggest.

Cheers,
Dave.
Comment 5 Dave Neary 2003-05-14 09:54:23 UTC
Excuse me - I added this comment thinking it was the "comment not
added when I do a screenshot" bug. 

Yes - this approach should work. We'll need to change all the file
loaders to attach a comment parasite (even if the format doesn't
support comments), but that sounds like a decent solution to me.

Cheers,
Dave.
Comment 6 Sven Neumann 2003-05-14 10:57:31 UTC
I don't think this is feasible. Not all file plug-ins are under our
control. If we do this change, we effectively introduce an API change
since we are changing how a correct file plug-in should behave. IMO we
should find a different solution.
Comment 7 Michael Natterer 2003-05-14 13:03:30 UTC
I'm strongly against that. The comment should be set whenever
creating a new image from scratch. The preferences page clearly
says "Comment used for new images" and I think every user can
understand that: If you create a new image, it will get this
comment.

We just need an "Image Properties" dialog which enables editing
the comment and that's it.

Doing voodoo on save is IMHO highly confusing and not
at all intuitive.

I propose closing this bug as WONTFIX.
Comment 8 Raphaël Quinet 2003-05-14 17:08:13 UTC
So if I understood Mitch correctly, we should do exactly the opposite
of what I suggested above: ensure that all possible ways of creating
an image in the GIMP (including from scripts and plug-ins) attach the
default comment and then keep that comment with the image until it is
saved, even if the user changes the default comment to something else
in the preferences.  Then the way to solve the apparently inconsistent
behavior (from a user's point of view) when the default comment is
changed is just a duplicate of bug #61499: implement a
File->Properties dialog so that the user can view and edit the current
comment attached to the image (without having to save it).  This also
means that it would not be fixed in the 1.2 branch, since bug #61499
is a 1.3.x thing.  If I understood correctly, then I agree with
WONTFIX or DUPLICATE.
Comment 9 Raphaël Quinet 2003-05-14 17:36:44 UTC
I should think twice before submitting my comments...

This bug report suggested to do the opposite of bug #51164: instead of
trying to attach the default comment in all cases, do not attach it
until the file is saved.  But now it looks like the best solution is
to do as described in bug #51164: always try to attach the default
comment.  So I think that WONTFIX is the best resolution for this one.

I also noticed that the comment I just added to bug #61499 about the
"use default comment" button is something that I already suggested on
2001-06-20 in a comment to bug #51164.  I'm really getting old...