Bug 141663

Created attachment 19690 [details]
Find out when the comment is changed

I cannot reproduce this here. Anyone else?

I you want to debug this further, attached is a patch which prints debug
messages when a change in the comment field occurs. In this case, you will read
a line
ImageDescEditTab::slotCommentChanged: the comment changed from...
The time when this line is printed is of interest.

Created attachment 19696 [details]
terminal output showing comments

These comments go with the prior attachment.

I applied your patch and the log is attached.  I've added some notes below and in the attachment that I hope will help you see what is going on.  I also noticed that for this to happen you must first edit at least one comment. 

1) First I clicked on several different images in 2 folders and everything okay. 
2) Next I edited image 20060622T103616-0044.JPEG with existing comment 'Boulder Colorado Foothills' to 'Mountains' and switch to another image (20060604_IMG_0037-2.png).  I am prompted to apply changes as expected. I click Yes.
3) I click to a different album and am immediately prompted to apply changes. Image 20050919_IMGS_0044_1.jpg is highlighted and already has "Cat on the Porch' comment. I click yes.
4) Next I click on another image (IMG_0124_2.jpg) with comment 'flower'. And am immediately prompted again. I click Discard.
5) Next click is on IMG_0126_1.jpg with comment 'porch'. The cycle continues.

I hope this helps. 
Thank you very much for Digikam.

Thanks for your debugging. But I still cannot reproduce this :-( This means more remote debugging is needed.
You identified the questionable calls to slotCommentChanged. It would be nice to get a backtrace for them. To do this, you can start digikam under gdb:
gdb digikam
run
Prepare the situation, change the comment to "mountains". Then go back to the console. Interrupt gdb with Ctrl+c and type
br 'Digikam::ImageDescEditTab::slotCommentChanged()'
cont
Now you can change the image. There will be multiple calls to this slot, each time you have to continue program execution with
cont
and you can get a backtrace with
bt
The interesting one is the backtrace immediately before the statement you identified. Of course, you can post all backtraces as well ;-)

Created attachment 19699 [details]
Backtrace as you requested.

I hope this helps.

SVN commit 634639 by mwiesweg:

Change this and that, without knowing if it is related to the bug

CCBUG: 141663


 M  +17 -6     imagedescedittab.cpp  


--- trunk/extragear/graphics/digikam/libs/imageproperties/imagedescedittab.cpp #634638:634639
@@ -448,10 +448,18 @@
     if (d->currInfos.isEmpty())
         return;
 
+    bool progressInfo = (d->currInfos.count() > 1);
     emit signalProgressBarMode(StatusProgressBar::ProgressBarMode,
                                i18n("Applying changes to pictures. Please wait..."));
     MetadataWriteSettings writeSettings = MetadataHub::defaultWriteSettings();
 
+    // debugging - use this to indicate reentry from event loop (kapp->processEvents)
+    // remove before final release
+    if (d->ignoreImageAttributesWatch)
+    {
+        kdWarning() << "ImageDescEditTab::slotApplyAllChanges(): re-entering from event loop!" << endl;
+    }
+
     // we are now changing attributes ourselves
     d->ignoreImageAttributesWatch = true;
     AlbumManager::instance()->albumDB()->beginTransaction();
@@ -464,7 +472,8 @@
         d->hub.write(info->filePath(), MetadataHub::FullWrite, writeSettings);
 
         emit signalProgressValue((int)((i++/(float)d->currInfos.count())*100.0));
-        kapp->processEvents();
+        if (progressInfo)
+            kapp->processEvents();
     }
     AlbumManager::instance()->albumDB()->commitTransaction();
     d->ignoreImageAttributesWatch = false;
@@ -508,11 +517,13 @@
 {
     if (infos.isEmpty())
     {
-       d->commentsEdit->clear();
-       d->currInfos.clear();
-       d->hub = MetadataHub();
-       setEnabled(false);
-       return;
+        d->hub = MetadataHub();
+        d->commentsEdit->blockSignals(true);
+        d->commentsEdit->clear();
+        d->commentsEdit->blockSignals(false);
+        d->currInfos.clear();
+        setEnabled(false);
+        return;
     }
 
     setEnabled(true);

Sorry - The patch did not fix it, but I have some new observations that may help. 

1) I do not have to switch to a different folder before the apply prompts start, this happens within the same folder on images that have different comments than the original.  It was just more noticeable with changing folders because the images in the new folder had different comments than the previous image.

2) if I select images with the same comment consecutively, I am not prompted.  Could it be comparing the comment of the two previous images instead of its own comment? Example below:

A "mountain"	initial image, change from "boulder" to "mountain", this kicks off the sequence
B "boathouse"	prompted immediately when switch to this image (change was made to A)
C "boathouse"	prompted immediately when switch to this image (compared A to B)
D "boathouse"	NOT prompted when switch to this image.(compared B to C)
E "cats"	NOT prompted when switch to this image. (compared C to D)
F "cats"	prompted immediately when switch to this image(compared D to E)
G "cats"	NOT prompted when switch to this image (compared E to F)
H "cats"	NOT prompted when switch to this image (compared F to G)

3) once a photo has been clicked/selected and I have been prompted and clicked apply, I am not prompted again for that picture.

4) I went back to try digikam-9.0.0 to see what it does. it looks like a similar symptom is there also.  9.0.0 will save the metadata for files when switching between images when no changes have been made. This can be seen when running from a terminal. 

You might try a test again with a bunch of different comments.
Hope this helps.

Created attachment 19723 [details]
example to go with previous comment

This also turns into a CRASH if I resize the digikam application window.  I receive many "Apply Changes?" dialog boxes as long as I re-size/reposition the window, some of which cannot be dismissed and I have to manually kill digikam and restart.  See screenshot on next comment.

Created attachment 19762 [details]
shows multiple apply comments boxes and locked up digikam

Marcel, I think this bug is important and must be fixed before 0.9.1-final release.

Gilles

After all I still cannot reproduce this problem.
To your example:

EXAMPLE

==> change the comment of the first image and click apply in bottom right corner

digikam: ImageDescEditTab::slotCommentChanged: the comment changed from "Mounta" to "Mountai
digikam: ImageDescEditTab::slotCommentChanged: the comment changed from "Mountai" to "Mountain
digikam: ImageDescEditTab::slotCommentChanged: the comment changed from "Mountain" to "Mountains
digikam: /home/gsking/Pictures/TEST/boulder.JPEG ==> Comment: Mountains
digikam: /home/gsking/Pictures/TEST/boulder.JPEG ==> Rating: 1
digikam: Dirty: /
digikam: Dirty: /TEST

==> click on next image Figure07.jpg "Boathouse" 

digikam: ImageDescEditTab::slotChangingItems: comment is changed? true  <--

This is fixed in SVN, but I suspect it was a Red Herring.

digikam: ImageDescEditTab::slotChangingItems: comment is changed? false 
digikam: ImageDescEditTab::setInfos with first file Figure07.jpg: comment is already changed? false
digikam: ImageDescEditTab::slotCommentChanged: the comment changed from "Boathouse" to "Boathouse <--

This is the part which I cannot reproduce. It seems to me that the backtrace you gave above was not from this call to slotCommentChanged (the bt above comes from "clear", so it would change from "Boathouse" to ""). With the SVN version, the call to clear will no longer come through to slotCommentChanged.
Do you have the SVN version? Than it would be great if you could give me all backtraces from slotCommentChanged as described above. There are not so many as before now.

Created attachment 19767 [details]
Backtrace as you requested using SVN. Will also attach screenshot

Created attachment 19768 [details]
Screenshot showing files and comments

Thought this might be relevant also.  As a contrast to the prior example, when the right side panel is set to "Metadata" and clicking through the files. The output from the terminal is like below and with no prompts:

digikam: ImageDescEditTab::slotChangingItems: comment is changed? false
digikam: ImageDescEditTab::slotChangingItems: comment is changed? false
digikam: ImageDescEditTab::slotChangingItems: comment is changed? false
Warning: Unsupported date format
Warning: Unsupported time format
digikam: ImageDescEditTab::slotChangingItems: comment is changed? false
digikam: ImageDescEditTab::slotChangingItems: comment is changed? false
digikam: ImageDescEditTab::slotChangingItems: comment is changed? false
digikam: ImageDescEditTab::slotChangingItems: comment is changed? false
digikam: ImageDescEditTab::slotChangingItems: comment is changed? false
digikam: ImageDescEditTab::slotChangingItems: comment is changed? false
Warning: Unsupported date format
Warning: Unsupported time format
digikam: ImageDescEditTab::slotChangingItems: comment is changed? false
digikam: ImageDescEditTab::slotChangingItems: comment is changed? false

Thanks! This is interesting:
KDictSpellingHighlighter::slotRehighlight()

It explains why there are text changes without you changing anything. I will try to fix this problem tomorrow.
After that I will try to find out how the Crash-like situation you described in #9 can occur.

Glad I could help.  I just installed digikam on another computer (ubuntu dapper) and am getting that message more consistently (below).  I'll be on vacation until late Monday with no computers. Also, thanks for the coaching.

digikam: KDictSpellingHighlighter::slotRehighlight()

Breakpoint 1, 0xb7d9ac4c in Digikam::ImageDescEditTab::slotCommentChanged () from /usr/lib/libdigikam.so.0
(gdb) bt
#0  0xb7d9ac4c in Digikam::ImageDescEditTab::slotCommentChanged () from /usr/lib/libdigikam.so.0
#1  0xb7da2d7a in Digikam::ImageDescEditTab::qt_invoke () from /usr/lib/libdigikam.so.0
#2  0xb63c1051 in QObject::activate_signal () from /usr/lib/libqt-mt.so.3
#3  0xb63c1aec in QObject::activate_signal () from /usr/lib/libqt-mt.so.3
#4  0xb677fd84 in QTextEdit::textChanged () from /usr/lib/libqt-mt.so.3
#5  0xb65536ad in QTextEdit::insert () from /usr/lib/libqt-mt.so.3
#6  0xb655373e in QTextEdit::insert () from /usr/lib/libqt-mt.so.3
#7  0xb655b515 in QTextEdit::insertAt () from /usr/lib/libqt-mt.so.3
#8  0xb6e59f8c in KDictSpellingHighlighter::slotRehighlight () from /usr/lib/libkdeui.so.4
#9  0xb6e5a165 in KDictSpellingHighlighter::slotCorrected () from /usr/lib/libkdeui.so.4
#10 0xb6e5a446 in KDictSpellingHighlighter::qt_invoke () from /usr/lib/libkdeui.so.4
#11 0xb63c1051 in QObject::activate_signal () from /usr/lib/libqt-mt.so.3
#12 0xb6d456ef in KSpell::corrected () from /usr/lib/libkdeui.so.4
#13 0xb6e5702b in KSpell::checkWord2 () from /usr/lib/libkdeui.so.4
#14 0xb6e57493 in KSpell::qt_invoke () from /usr/lib/libkdeui.so.4
#15 0xb63c1051 in QObject::activate_signal () from /usr/lib/libqt-mt.so.3
#16 0xb6a4dda8 in KProcIO::readReady () from /usr/lib/libkdecore.so.4
#17 0xb6a4debb in KProcIO::controlledEmission () from /usr/lib/libkdecore.so.4
#18 0xb6a4df79 in KProcIO::received () from /usr/lib/libkdecore.so.4
#19 0xb6ab56ff in KProcIO::qt_invoke () from /usr/lib/libkdecore.so.4
#20 0xb63c1051 in QObject::activate_signal () from /usr/lib/libqt-mt.so.3

SVN commit 636631 by mwiesweg:

Check that the text actually changed in slotCommentChanged

CCBUG: 141663


 M  +7 -1      imagedescedittab.cpp  


--- trunk/extragear/graphics/digikam/libs/imageproperties/imagedescedittab.cpp #636630:636631
@@ -457,7 +457,7 @@
     // remove before final release
     if (d->ignoreImageAttributesWatch)
     {
-        kdWarning() << "ImageDescEditTab::slotApplyAllChanges(): re-entering from event loop!" << endl;
+        DWarning() << "ImageDescEditTab::slotApplyAllChanges(): re-entering from event loop!" << endl;
     }
 
     // we are now changing attributes ourselves
@@ -669,6 +669,12 @@
 
 void ImageDescEditTab::slotCommentChanged()
 {
+    // we cannot trust that the text actually changed
+    // (there are bogus signals caused by spell checking, see bug 141663)
+    // so we have to check before marking the metadata as modified
+    if (d->hub.comment() == d->commentsEdit->text())
+        return;
+
     d->hub.setComment(d->commentsEdit->text());
     setMetadataWidgetStatus(d->hub.commentStatus(), d->commentsEdit);
     slotModified();

This fixed it. Thanks.

Also, no more crashes like #9
Changed to resolved.