Eog creates thumbnails even when deactivated in gnome

[tricky1]

Binary package hint: eog

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.

Eog 2.22.2 on Ubuntu 8.04.1

[Pedro Villavicencio (pedro)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. Unfortunately we can't fix it, because your description didn't include enough information. You may find it helpful to read "How to report bugs effectively" http://www.chiark.greenend.org.uk/~sgtatham/bugs.html. We'd be grateful if you would then provide a more complete description of the problem.
 We have instructions on debugging some types of problems. http://wiki.ubuntu.com/DebuggingProcedures
At a minimum, we need:
1. the specific steps or actions you took that caused you to encounter the problem,
2. the behavior you expected, and
3. the behavior you actually encountered (in as much detail as possible).
Thanks!

[tricky1 (tricky1)]

Well I thought that my description explained it all ...

1. the specific steps or actions you took that caused you to encounter the problem:

a) Disable creation of thumbnails in nautilus settings.
b) Clear the thumbnails folder
c) Watch some pics using eog

2. the behavior you expected:
No thumbnail pics created in thumbnails folder.

3. the behavior you actually encountered:
For each pic watched in step c there is a thumbnail created in thumbnail folder.

This may result in thousands of thumbnails created...
If you still have questions do not hesitate to ask.

[tricky1 (tricky1)]

On a second system same bug

[Sebastien Bacher (seb128)]

don't confirm your own bug

[Andreas Moog (ampelbein)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. I reported this issue upstream, you can track the status and make comments here: http://bugzilla.gnome.org/show_bug.cgi?id=551171

[mjc (mjc-avtechpulse)]

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

[arQon (arqon)]

It's not about "paranoia" Mike: it's that a user who has explicitly stated that they don't want thumbnails, ever; in the only place they *can* specify that preference, is given the impression that their decision is being ignored. I don't think you can blame them for considering it to be a bug.

eog certainly does not have the "right" to ignore user instructions, and especially not in a case like this where it has noticeable negative impacts (slow startup times in extreme cases, disk thrash, and so on) and provides no benefit at all to those users (or indeed to *any* user by default IIRC, because thumbnail display isn't even enabled).

Deleting the thumbnails after the fact doesn't address any of those issues (and in fact makes them worse, since eog will then re-thrash).
A better option is to just symlink ~/.thumbnails to /dev/null, but that obviously means that if you ever do actually want a thumbnail for some reason, you can't have it.

This particular bug seems to be filed repeatedly in every distro, but nobody will take ownership of it. Whether the bug is that eog doesn't have its own setting or it doesn't honor Nautilus's is for them to decide, but failing to address it by either approach for 8? years now is ridiculous.

Felix said in https://bugzilla.gnome.org/show_bug.cgi?id=633292 that the thumbnails were "necessary". Since he's the eog maintainer it seems unlikely GNOME will ever fix this bug, though that claim is perhaps a little misleading: the only thing that "needs" thumbnails is the "image collection" pane, and imposing this overhead regardless of whether someone actually uses that feature or not seems completely unjustified to me.

--

[snipped a bunch of performance numbers]

To sum up, the CPU overhead of thumbnails is meaninglessly-small, especially since eog is keypress/timer driven anyway. Between JPEG decoding, image resizing, etc, generating a 128x128 PNG from a pixbuf is barely a blip.
The IO overhead of thumbnails OTOH can be quite significant, and warrants "fixing" (ie "honoring user preference") for the annoyance factor alone, especially since the current behavior is "wrong" anyway for the defaults eog/ubuntu uses.

[snipped discussion of some other eog bugs i noticed along the way: they're noted in the patch]

--

patch is against eog-2.32.1 (15 Nov 2010), which is the current stable, though lucid is still using 2.32.0

hopefully it'll save someone some time/frustration even if it never gets merged upstream.

[mjc (mjc-avtechpulse)]

gnome imaging apps follow the freedesktop.org thumbnailing spec:
http://people.freedesktop.org/~vuntz/thumbnail-spec-cache/

There is no gnome-wide disable-thumbnail setting, and I doubt you'll convince anyone that it is worth having one. (Part of the probably is that nautilus, gthumb, and eog can be present on a system in any combination.) gnome generally tries to minimize the number of user settings. That's controversial, and kde takes a different approach, but it is the general gnome approach.

gThumb has a disable-thumbnail setting, although it can only be enabled through gconf-editor. Maybe you can convince eog to do the same, but such a patch would have to go upstream.

However: have you tried "chmod -R 550 ~/.thumbnails"? Making ~/.thumbnails read-only would probably resolve your issue. (If it doesn't, that would be a serious bug.)

- Mike

[Sebastien Bacher (seb128)]

the "patch" seems rather a workaround than a fix, dropping it from the patch list it's not something that should go on the ubuntu review list

[arQon (arqon)]

> There is no gnome-wide disable-thumbnail setting, and I doubt you'll convince anyone that it is worth having one.

Exactly so Mike: except that piece appears to have been oversnipped from my notes, yay 4am editing...

> gThumb has a disable-thumbnail setting, although it can only be enabled through gconf-editor. Maybe you can convince eog to do the same

Which is exactly what I did, but you'd have had to read the patch to see it since I didn't make that clear. My bad.

The chmod "fix" isn't a fix for the same reason that dev/null isn't. A user may want thumbs for a photo collection in Shotwell/etc or a set of "active" images, but not want them for images sent in email etc where they just use eog to view them once (which now that I think of it is a perfect example of a case where mindless thumb creation is an especially-bad policy).

Here's the rest of the notes:

===

These bugfixes expose 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).

This is a major design error rather than a simple implementation bug, but the bigger problem is image_thumb_changed_cb() failing to handle null thumbnails correctly. Since that's a valid return from eog_thumbnail_load(), this is a pre-existing bug in eog (##). The best fix for that bug is probably to just use
"image-loading" or "image-missing", and that's very convenient, because correcting the design would be a huge amount of work, but once we have this other fix we can leverage that to fix the original bug as well, like so:

eog_thumbnail_load (EogImage *image, GError **error)
{
 g_object_ref( eog_missing_image );
 return eog_missing_image;
}

and all we have to do to wrap things up is add eog_missing_image to eog-thumbnail.c as a static and initialise it in eog_thumbnail_init.

## This bug may well be what Felix really meant: it's not so much that there are any "genuine" reasons for the thumbnail-dependency, just that there are parts of the implementation that don't cope properly with them being absent.

Given the existing code this is about as non-invasive as you can get; and it fixes the bug. Those are two pretty compelling arguments for it as a solution.

Note that this is the *correct* implementation of a Nautilus-equivalent "Never Create Thumbnails" setting.
It's arguably not the most *desirable* implementation for eog though, because it essentially makes the "image collection" function useless. Preserving support for that is only slightly more work: all you have to do is replace the flag with a policy: "Never; RAM-only; Persistent" and add another half-dozen lines. So I've done that too.
Although I personally don't find "image collection" useful anyway, even that second appr...

[mjc (mjc-avtechpulse)]

arqon,

You should forward your notes to the eog mailing list (http://mail.gnome.org/mailman/listinfo/eog-list). I'm sure they'd appreciate hearing about the problems you've noted in the design of their collection viewer. Especially if you provide them with a patch fixing the design problems and slipping in your gconf setting :-)

No distro is going to take a patch like this without upstream support, however, so I encourage you to use the eog mail list and the gnome bugzilla.

- Mike

[arQon (arqon)]

replaced the patch with a debdiff (was rcs) and used the gnome bug id rather than a distro-specific one. semi-pointless i know, but it'll be easier for anyone who wants to patch eog themselves.

[arQon (arqon)]

and sent to the mailing list, which is what i actually came here to post but forgot...

heh - i'm not going to redesign and rewrite *that*, Mike: it's so integral it would probably be quicker to just start again from (near-)scratch. it's not ideal, but it seems to work for everything outside of the pathological cases i spotted, so i think i'll stick to lower-hanging fruit instead. :P

thanks for the feedback/suggestions/etc

[Sebastien Bacher (seb128)]

Thank for updating it, the patch named "foo" not using the -u format and without explanation was not really easy to review, could you explain what you are doing there exactly and why? it seems you are mostly dropping code, why is that code not required?

[arQon (arqon)]

other way around sebastien: those are all added lines. which i guess means the files were diffed the wrong way round, sigh - i'm used to real sccs's, not diffpatches. thanks for spotting it: re-uploaded with the inversion fixed