GNOME Bugzilla – Bug 555370
eog should auto-refresh when file changes
Last modified: 2019-02-22 03:15:25 UTC
the bug has been described on https://bugs.launchpad.net/ubuntu/+source/eog/+bug/279471 "Binary package hint: eog For example: cp red.jpg image.jpg eog image.jpg & cp blue.jpg image.jpg eog will keep showing the red image, even if I re-select image.jpg from the recent files list. The use case is when I'm working on a program that outputs an image, and I keep rerunning my program on each iteration. As it is, I have to use something like kview or gwenview to avoid constantly restarting my viewer just to see the latest iteration. Even pressing alt-f,1 in eog would probably make me switch back."
EOG 2.24 ships with the Reload plugin that should help here already. Once enabled it will add a tools menu to the menubar with a Reload Image command that will reload the current image. It adds an Ctrl-Shift-R shortcut as well if you prefer to use the keyboard. Unfortunately no toolbar button yet.
Ctrl-Shift-R is not exactly what i would call a shortcut. Since eog doesn't take text input, one could use just "r" instead, couldn't one? That would make the short a lot easier to use, especially for people who are not that agile with their fingers anymore.
(In reply to comment #2) > Since eog doesn't > take text input, one could use just "r" instead, couldn't one? Thanks for that hint. Using that now, so we can use the more complicated one elsewhere. :-)
*** Bug 503837 has been marked as a duplicate of this bug. ***
Updating bug properties to reflect the plugin enhancement request.
Isn't it possible for eog to use the filesystem signals to autoupdate?
There is bug #534348 which request reload via inotify or at least do a reload check on focus-in. It would also rock, if the reload plugin could provide an action for the toolbar, so that one can add it there.
Newer eog versions (I think >=2.32) are now asking to reload modified images (bug 534348). This is pretty much what you want, except that you need to confirm the reload. As it solves your use case and as an automatic reload is potentially "dangerous" (it could revert unsaved modifications), I'm seeing this as fixed. This problem has been fixed in our software repository. The fix has been releases with eog-2.32. Thank you for your bug report. P.S. Adding toolbar items by plugins is still not supported, as it would cause a race with plugin loading when starting eog (the plugin's action might not be there yet, which would drop it from the toolbar).
(In reply to comment #8) > Newer eog versions (I think >=2.32) are now asking to reload modified images > (bug 534348). This is pretty much what you want, except that you need to > confirm the reload. As it solves your use case and as an automatic reload is > potentially "dangerous" (it could revert unsaved modifications), I'm seeing > this as fixed. It would be lovely if you could just reload, if there are no modifications done. E.g. I am using eog as a pure viewer and don't modify images in it.
(In reply to comment #9) > (In reply to comment #8) > > Newer eog versions (I think >=2.32) are now asking to reload modified images > > (bug 534348). This is pretty much what you want, except that you need to > > confirm the reload. As it solves your use case and as an automatic reload is > > potentially "dangerous" (it could revert unsaved modifications), I'm seeing > > this as fixed. > > It would be lovely if you could just reload, if there are no modifications > done. E.g. I am using eog as a pure viewer and don't modify images in it. Sounds good to me.
Created attachment 197900 [details] [review] patch: autoreload unmodified images Dumping patch here until we branch of the stable tree from master.
Checked into git master: commit 3764db24f7d5e570b39894a05ba71a09012eea24 Author: Felix Riemann <> Date: Fri Sep 30 20:30:16 2011 +0200 Auto-reload unmodified images when their file is changed It makes sense to skip the user confirmation in this case as there are no unsaved changed that could get lost. https://bugzilla.gnome.org/show_bug.cgi?id=555370 This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.