Bug 203732

Summary: Image captions changed (from first image) when applying metadata template to group of photos
Product: [Applications] digikam Reporter: Michał S. <michau>
Component: Metadata-TemplateAssignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: caulier.gilles, knizek, marcel.wiesweg
Priority: NOR    
Version: 1.0.0   
Target Milestone: ---   
Platform: Compiled Sources   
OS: Unspecified   
Latest Commit: Version Fixed In: 7.6.0
Sentry Crash Report:

Description Michał S. 2009-08-13 17:16:24 UTC 
Version:           1.0.0-beta3 (using Devel)
Installed from:    Compiled sources

When I apply metadata template (new digiKam featrue from recent beta versions) to a group of photographs also image captions (IPTC and XMP related fields) are changed and set from FIRST image in album view. So, if I select all photos in given album, apply metadata template to them and the first image has empty caption, all captions in images are gone. Similar when first image has caption 'foo' all images will be set will 'foo' caption.

This is very unwanted behaviour.
Comment 1 caulier.gilles 2009-08-14 11:59:37 UTC 
Can you test with current code from svn (beta4) where a lots of code have changed about template metadata managemenent ?

Gilles Caulier
Comment 2 Michał S. 2009-08-16 01:02:03 UTC 
(In reply to comment #1)
> Can you test with current code from svn (beta4) where a lots of code have
> changed about template metadata managemenent ?
> Gilles Caulier

Unfortunately not, because I've got app installed from openSUSE trunk repos and there is digiKam 1.0.0-beta3 version, I do not compile digiKam from sources by myself. But I've posted ask to Digikam-users list, maybe someone there will check this.
Comment 3 Milan Knížek 2009-08-17 12:22:09 UTC 
The bug is still there. (In my case, the _last_ selected image's caption gets distributed to any other image being changed by the template.)
Comment 4 Marcel Wiesweg 2009-09-11 18:50:46 UTC 
Confirmed. We must fix this bug for next beta.

Gilles, it is caused by these two lines 544-545 in ImageDescEditTab::slotApplyAllChanges():

    d->captionsEdit->apply();
    slotCommentChanged();

For what are they needed? As a side effect, slotCommentChanged() will mark the comment as changed as if edited by the user, so it will be applied to all images.
Comment 5 Marcel Wiesweg 2009-09-11 19:19:05 UTC 
Another related problem:
--- a/libs/template/altlangstredit.cpp
+++ b/libs/template/altlangstredit.cpp
@@ -460,7 +460,7 @@ void AltLangStrEdit::slotTextChanged()
     QString text = d->valueEdit->toPlainText();
     if (text.isEmpty())
     {
-        d->addValueButton->setEnabled(false);
+        slotDeleteValue();
         return;
     }

which makes removing a comment intuitive (just remove the text)
Comment 6 Marcel Wiesweg 2009-09-11 19:49:26 UTC 
SVN commit 1022407 by mwiesweg:

Adjust behavior of caption edit so that the caption is marked as edited if and only
if the user edited it. Additionally, do not discard the change if the user removed
the text in the caption edit box to remove the comment.

CCBUG: 203732

 M  +2 -0      imageproperties/captionedit.cpp  
 M  +0 -1      imageproperties/imagedescedittab.cpp  
 M  +3 -2      template/altlangstredit.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1022407
Comment 7 Sean Reifschneider 2009-09-15 16:38:05 UTC 
Just another data-point, I believe I am seeing this same issue.   In my case, I am using beta4, and I can reproduce the bug by doing this:

Select an image.
Enter a caption.
Right-click to select another image as well as the first image.
Set some tags.
Click apply.

In this case the comment from the second image (which in my case is usually empty) is applied to the first image.

The reverse would also be true, if I:

Select an image without a comment, or with a different comment.
Control-click to select another image with a comment.
Change tags.
Apply.

In this case the comment of the second selected image is applied to the first.

Thanks,
Sean
Comment 8 Marcel Wiesweg 2009-09-21 19:15:03 UTC 
Sean, are you using a version including or not including my fix from 09/11?
Comment 9 Marcel Wiesweg 2009-11-30 20:23:53 UTC 
Sean, any update here?
Comment 10 Marcel Wiesweg 2010-03-17 21:41:12 UTC 
Probably fixed since 1.0, no feedback.