GNOME Bugzilla – Bug 551171
Eog creates thumbnails even when deactivated in nautilus
Last modified: 2021-06-19 08:46:15 UTC
Please describe the problem: Eog itself does not have a dialogue to deactivate creation of thumbnails. So one would assume that it would follow the settings given in nautilus. However, it does always create ./thumbnails/normal/suchAndsuch.png (even if the directory 'normal' has been deleted. Steps to reproduce: 1) Disable creation of thumbnails in nautilus settings. 2) Clear the thumbnails folder 3) Watch some pics using eog Actual results: For each pic watched in step c there is a thumbnail created in thumbnail folder. This may result in thousands of thumbnails created... Expected results: No thumbnail pics created in thumbnails folder. Does this happen every time? Yes Other information: This issue was reported on Launchpad: https://bugs.edge.launchpad.net/ubuntu/+source/eog/+bug/255030
Nautilus and eog are two different applications. Your assumption that they share settings is not a safe one. However, in gnome-2.24, the paranoid can use gconf-editor to set: /desktop/gnome/thumbnail_cache/maximum_age or /desktop/gnome/thumbnail_cache/maximum_size to zero, and all thumbnails will be deleted when you log out. - Mike
*** Bug 633292 has been marked as a duplicate of this bug. ***
Created attachment 184317 [details] [review] add support for no-thumbnailing option like nautilus/gthumb/etc patch is against 2.32.1, ie current stable apps/eog/thumbnail_policy (int) 0 - Never create thumbnails (or use them even if they exist). This matches the behavior of the Nautilus setting. 1 - Create and use thumbnails, but don't write them to disk. This preserves all of the current functionality while removing the IO thrash (nice for SSD, important for USB or non-local /home) 2 - Save thumbnails As pre-patch -- Note: This exposed an interesting bug in eog where the "Properties" page fails to update properly on Next/Prev if thumbnails are disabled. This appears to be because it's using eog_thumb_view_select_single() to step through the list rather than the actual images themselves. It correctly advances the MAIN window to the next image, but since it's dereferencing the wrong object for the dialog, not only does that not update, but attempting to get the properties of any image always shows those of the one from the first USE of the properties dialog (not necessarily the first image in the directory). The fix in the patch doesn't suffer from that "incorrect properties" bug (even at 0) - it's just something that showed up during development of the patch. The patch highlights and explains that second bug and at least partially fixes it, but could use review by someone more familiar with eog.
Comment on attachment 184317 [details] [review] add support for no-thumbnailing option like nautilus/gthumb/etc patch was inverted, uploaded new copy - no actual code changes
Created attachment 184438 [details] [review] support thumbnail creation flag like nautilus/gthumb/etc
I'm using now Eye of Gnome 3.5.91 and it seems to doesn't create any thumbnails anymore. The curious is that it doesn't even create thumbnails if it is enabled in my filemanager (PCManFM). Only looking into a folder with pictures with PCManFM will create thumbnails.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/eog/-/issues/ Thank you for your understanding and your help.