Version: 2.6 (using KDE 4.6.2) OS: Linux In Gwenview running on KDE 3.x, I was able to set the viewer to a certain jpg file that, by design, periodically updated. GV for KDE3 would automatically reload the image when it detected that the file had been changed. GV for KDE4 does not do this and provides no options to allow this desired behaviour. Reproducible: Always Steps to Reproduce: Load an image file, use another program to overwrite the image file with another image, watch nothing happen. Manually reloading the image file works as expected, but requires the manual part. Actual Results: Gwenview continues to display the original copy of the image file. Expected Results: Gwenview should display the newest version of the image file (or at least provide this as an option).
I have exactly the same problem. Changing an image by another program (e.g. just change the date with "exiftran -api image.jpg"), requires a restart of gwenview in order to display the newest version there. Gwenview 2.6.0 KDE 4.6.0 Linux (x86_64) release 2.6.37.6-0.7-desktop
Sorry, I wanted to say: [...] just change the date with "touch image.jpg" [...] Interestingly, a "exiftool '-DateTimeOriginal>FileModifyDate' image.jpg" causes gwenview to reload and display the correct date again.
I can reproduce the problem using master code. The strange thing is after the image is updated or overwritten, I can see in the browser mode that the thumbnail has changed accordingly, but opening that file in view mode still show the old image.
*** Bug 296185 has been marked as a duplicate of this bug. ***
If you hesitate to implement a function, that constantly polls the file-system for latest modification times, it would already be great, to read the timestamps (and act on detection of changes) once gwenview regains the focus from another window. This would easily cover the most common usecase of modifying&saving the pic with some external editor and switching back to gwenview to e.g. compare the result with the original.
(In reply to comment #5) > read the timestamps (and act on detection of changes) once gwenview regains > the focus from another window. I don't entirely agree here. Once the image has been displayed in gwenview, it should stay with current version of the pic even on refocus. One can press reload (F5) manually to display the modified version. There is no need for a filewatcher or read of timestamps in that case. What we need here is rather a sync of the cached image only upon clicking the thumbnail.
(In reply to comment #6) > I don't entirely agree here. Once the image has been displayed in gwenview, > it should stay with current version of the pic even on refocus. One can > press reload (F5) manually to display the modified version. There is no need > for a filewatcher or read of timestamps in that case. What we need here is > rather a sync of the cached image only upon clicking the thumbnail. If the "file watcher" is implemented, I hope it can be implemented with linux's inotify system. So when the image is rewritten in background, it should also be automatically refreshed immediately in gwenviewer. Focus event should not be cared for this problem. Gnome's image viewer has the similar feature. With that, I can easily write a script to project slides or test a CG project. If someone doesn't like the feature, I think an option can solve the problem.
(In reply to comment #7) > If the "file watcher" is implemented, I hope it can be implemented with > linux's inotify system. So when the image is rewritten in background, it > should also be automatically refreshed immediately in gwenviewer. Focus > event should not be cared for this problem. Could one use the Qt-class QFileSystemWatcher for this feature? On a fileChanged() signal one would reload the image. > If someone doesn't like the feature, I think an option can solve the problem. Shall we have a CheckBox "Automatically update displayed images" somewhere in the settings?
As bug 316981 demonstrates, Gwenview already tracks some file-system-events for deleting images. It would be more consistent to also track changed files. If you want a more static behavior, I'd be happy with an extra option. In addition a commandline-parameter for enforcing that new option for one running instance would solve the issue of bug 316981 with deleted temp-files.
*** This bug has been marked as a duplicate of bug 131068 ***