Bug 141663 - Keep getting prompted to Apply Comments
Summary: Keep getting prompted to Apply Comments
Status: RESOLVED WORKSFORME
Alias: None
Product: digikam
Classification: Applications
Component: Albums-MainView (show other bugs)
Version: 0.9.1
Platform: unspecified Linux
: VHI normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-02-14 00:34 UTC by Geoff King
Modified: 2012-09-06 11:32 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In: 0.9.1
Sentry Crash Report:


Attachments
Find out when the comment is changed (1.11 KB, patch)
2007-02-14 16:43 UTC, Marcel Wiesweg
Details
terminal output showing comments (5.49 KB, text/plain)
2007-02-15 00:51 UTC, Geoff King
Details
Backtrace as you requested. (7.64 KB, text/plain)
2007-02-15 23:41 UTC, Geoff King
Details
example to go with previous comment (4.47 KB, text/plain)
2007-02-18 03:50 UTC, Geoff King
Details
shows multiple apply comments boxes and locked up digikam (152.64 KB, image/jpeg)
2007-02-20 19:37 UTC, Geoff King
Details
Backtrace as you requested using SVN. Will also attach screenshot (16.23 KB, text/plain)
2007-02-20 23:47 UTC, Geoff King
Details
Screenshot showing files and comments (165.62 KB, image/jpeg)
2007-02-20 23:49 UTC, Geoff King
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Geoff King 2007-02-14 00:34:37 UTC
Version:           0.9.1-beta1 (using KDE 3.5.6, Kubuntu (edgy) 4:3.5.6-0ubuntu1~edgy1)
Compiler:          Target: i486-linux-gnu
OS:                Linux (i686) release 2.6.17.14-ubuntu1

A dialog box keeps prompting me to apply changes when I do not want/need to since I have not made any changes:

To make this happen:
1) Comments/Tags on right side is open, but am not editing anything.
2) Click on a few images in the current album, then
3) Switch to another album and click on a few more images with different comments
4) I am prompted even though I did not make any changes to the comments. 

The dialog box reads:
"You have edited the comment of the picture. Do you want to apply your changes?"

As far as I can tell in one instance it changed the:
'File Modification Date/Time' -current date
'Software' - more recent version of digikam
'Program Version' - more recent version of digikam
'Thumbnail Offset'
I presume it also updated the 'Comment' and other EXIF/IPTC fields.
Comment 1 Marcel Wiesweg 2007-02-14 16:43:50 UTC
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.
Comment 2 Geoff King 2007-02-15 00:51:46 UTC
Created attachment 19696 [details]
terminal output showing comments
Comment 3 Geoff King 2007-02-15 00:52:59 UTC
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.
Comment 4 Marcel Wiesweg 2007-02-15 19:06:30 UTC
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 ;-)
Comment 5 Geoff King 2007-02-15 23:41:59 UTC
Created attachment 19699 [details]
Backtrace as you requested.

I hope this helps.
Comment 6 Marcel Wiesweg 2007-02-17 23:02:53 UTC
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);
Comment 7 Geoff King 2007-02-18 03:49:59 UTC
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.
Comment 8 Geoff King 2007-02-18 03:50:57 UTC
Created attachment 19723 [details]
example to go with previous comment
Comment 9 Geoff King 2007-02-20 19:36:22 UTC
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.
Comment 10 Geoff King 2007-02-20 19:37:30 UTC
Created attachment 19762 [details]
shows multiple apply comments boxes and locked up digikam
Comment 11 caulier.gilles 2007-02-20 19:41:23 UTC
Marcel, I think this bug is important and must be fixed before 0.9.1-final release.

Gilles
Comment 12 Marcel Wiesweg 2007-02-20 22:25:13 UTC
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.
Comment 13 Geoff King 2007-02-20 23:47:32 UTC
Created attachment 19767 [details]
Backtrace as you requested using SVN. Will also attach screenshot
Comment 14 Geoff King 2007-02-20 23:49:17 UTC
Created attachment 19768 [details]
Screenshot showing files and comments
Comment 15 Geoff King 2007-02-21 01:39:43 UTC
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



Comment 16 Marcel Wiesweg 2007-02-21 23:03:56 UTC
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.
Comment 17 Geoff King 2007-02-22 03:31:56 UTC
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
Comment 18 Marcel Wiesweg 2007-02-23 17:29:17 UTC
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();
Comment 19 Geoff King 2007-02-27 05:15:26 UTC
This fixed it. Thanks.
Comment 20 Geoff King 2007-02-27 05:18:26 UTC
Also, no more crashes like #9
Changed to resolved.