Version: unspecified (using KDE 4.6.2) OS: Linux open dolphin, navigate to any dir with images, let the thumbnailer do its work. Now change one of the files in the dir with an external program, say gwenview (Plugins->images->black&white e.g.) Watch the image in dolphin - nothing happens. Reproducible: Always Expected Results: dolphin should update its thumbs on external change. BTW even IN gwenview itself the image is NOT CHANGED when applying a plugin (like images/black&white) on it - you can't see the change. OS: Linux (x86_64) release 2.6.35-28-generic Compiler: cc
maybe it's not a dolphin bug but a kio_* ?
I cannot reproduce the issue in my environment (the thumbnails get updated correctly when they are changed from outside). The code for handling this is not in Dolphin but in kdelibs. AFAIK inotify is used per default and fam as fallback in Linux. Probably you could check whether you've activated at least one of those 2 things in your environment.
Yes, that was my first thought too. But Kate seems wo work well with that. If I externally change an (in Kate) open file, kate immanently asks me if it should be reloaded because changed. But Dolphin/Gwenview don't get that changes. I did another test. I created a text file name "blah.txt" with the content "blah", switched on preview for text files in dolphin and changed the content into "lah" using nano on the command line. I also had Kate opened that file. Kate asked me to reload, and Dolphin showed me the correct preview in the view. So the problems only occur with images. What else could I test?
I tested as another user - the preview thumb is updated correctly, only the preview on the information sidebar right is old until I hover over the image again. (this is maybe another, cosmetical, bug) So it seems it is part of my misconfig in some .kde config file. Should I do some more tests? If you dom't mind you can close this bug otherwise (invalid).
Oh no. Back again. The thumbnails in dolphin update correct if I rotate the pictures using gwenview. The problem seems to be in gwenview, or its plugins: rotating using the normal gwenview function is fine, but could you try exactly: open a jpg image with gwenview (I got 2.6.0 on KDE SC 4.6.2), Menu Plugins->Images->Convert to Black&White What happens then? Here, my picture in Gwenview and in the dolphin preview is still coloured, but if I open it again with any viewer, it really IS B/W. So somehow the problem seems to be in updating after a gwenview plugin? Do they undergo the inotify system somehow?
I also had no problems when changing a text-file with kate, the preview got updated correctly. Rotating a file in Gwenview also results in an update of the image, but when using the a plugin no update is done... Initially I guessed this might happen if the filesize does not change, but doing some tests with texts show that having the same filesize is no problem. Checking the modification time of the file indicates that when using such a plugin no file change has been done. My current guess is that the plugins preserve the modification time of a file on purpose, so that e.g. it is still known when "the photo" has been taken. As also the file size does not change I guess this bypasses the notification system in KDE. I'd suggest to leave this issue open, probably David has some time in 2015 [1] to check whether we should just blame the plugins or whether the notification system can be improved to notice such a "hidden change". [1] Internal running gag ;-)
(In reply to comment #6) > I also had no problems when changing a text-file with kate, the preview got > updated correctly. Rotating a file in Gwenview also results in an update of the > image, but when using the a plugin no update is done... > > Initially I guessed this might happen if the filesize does not change, but > doing some tests with texts show that having the same filesize is no problem. > > Checking the modification time of the file indicates that when using such a > plugin no file change has been done. > > My current guess is that the plugins preserve the modification time of a file > on purpose, so that e.g. it is still known when "the photo" has been taken. As > also the file size does not change I guess this bypasses the notification > system in KDE. > > I'd suggest to leave this issue open, probably David has some time in 2015 [1] > to check whether we should just blame the plugins or whether the notification > system can be improved to notice such a "hidden change". > > [1] Internal running gag ;-) Since my name is close enough to David's, I guess I can step in short circuit this one for him so he has one less thing to worry about in 2015 :). Peter is correct. According to my test, the plugin for converting the image to B&W does not seem to change the modification date and hence the problem. I doubt there is a viable workaround for this except to inform the plugin creators of the issue. Since information such as creation date can be extracted from image meta-data for most image formats today, I do not see why they do not properly update the image file's modification date. Anyhow, this needs to be kicked over to the kipi-plugin creator(s). If they do not change it, then there will be no fix for this.
BatchProcessImage is not maintained since a while and is obsolete now. It will be removed with 5.0.0. Use digiKam BQM instead...