GNOME Bugzilla – Bug 699252
fails to generate thumbnails for xpm files with comments in header
Last modified: 2013-09-20 10:41:06 UTC
Created attachment 242833 [details] Test file that fails If a .xpm file has a (quite unconventional, I admit) header in this form: // This file is part of BOINC. // http://boinc.berkeley.edu // /* XPM */ static const char *atiicon_xpm[] = { ... libgnome-desktop fails to generate a thumbnail preview for it. First I thought this could be a CRLF issue, or perhaps the '//'-style comments instead of '/* */', but even changing both, thumbnails still failed to generate. I also assumed such files were invalid, but EOG, the default image viewer in Gnome, displays them fine. And both eog and libgnome-desktop uses GdkPixbuf, so it is not a bug in GdkPixbuf either. Maybe eog is pre-processing the file, or using GdkPixbuf in a different way that allows such files to render? Can libgnome-desktop do the same? Examples of such XPM files are found at http://boinc.berkeley.edu/trac/export/HEAD/boinc-v2/clientgui/res/
Created attachment 252966 [details] [review] gs_file_read_noatime: Always return errors When passed an invalid GFile, we should error out properly instead of not returning an error.
Created attachment 252967 [details] [review] thumbnailer: Always print errors from gs_file_read_noatime()
Created attachment 252968 [details] [review] thumbnailer: Correctly check for errors By checking the retval, not whether error was set.
Created attachment 252969 [details] [review] thumbnailer: Check gdk_pixbuf_loader_close()'s retval
A few bug fixes above, but it seems to get thumbnailed fine: ./test-desktop-thumbnail file:///home/hadess/atiicon.xpm shows a nice thumbnail in a separate window. Did you pass a filepath instead of a URI? Marking as NEW for the bug fixes.
Review of attachment 252966 [details] [review]: It's not invalid, it's just non-local. Besides that minor quibble with the commit message, looks fine to me!
Review of attachment 252967 [details] [review]: Looks fine.
Review of attachment 252968 [details] [review]: Checking that GError was set is valid, but this code is definitely cleaner.
Review of attachment 252969 [details] [review]: Sure; the == FALSE looks odd to me...but I guess gnome-pnp-ids.c does it too.
@Bastien: I didn't try to thumbnail it directly, I let Nautilus do so, and tested by deleting ~/.thumbnails and navigating back to the folder containing the xpm files. That directory is local, so perhaps Nautilus is passing a filepath to thumbnailer instead of an URI? A few helpful notes: - The xpm test files were fixed by upstream boinc, so disregard the examples URL in my first post and use only the attachment. - When I opened the attachment myself (Using Firefox's "Open With"), Nautilus DID generate a thumbnail for the automatically downloaded file at /tmp. But if instead I select "Save File", or copy the file somewhere else, it doesn't. - Using Ubuntu 12.04 64 bit, Firefox 23, Nautilus 3.4.2
(In reply to comment #6) > Review of attachment 252966 [details] [review]: > > It's not invalid, it's just non-local. Besides that minor quibble with the > commit message, looks fine to me! It's either invalid (try passing a local path instead of a URI to test-desktop-thumbnail) meaning that somebody passed garbage to g_file_new_for_uri(), or isn't backed by a fuse mount or native. (In reply to comment #10) > @Bastien: I didn't try to thumbnail it directly, I let Nautilus do so, and > tested by deleting ~/.thumbnails and navigating back to the folder containing > the xpm files. > > That directory is local, so perhaps Nautilus is passing a filepath to > thumbnailer instead of an URI? > > A few helpful notes: > > - The xpm test files were fixed by upstream boinc, so disregard the examples > URL in my first post and use only the attachment. > > - When I opened the attachment myself (Using Firefox's "Open With"), Nautilus > DID generate a thumbnail for the automatically downloaded file at /tmp. But if > instead I select "Save File", or copy the file somewhere else, it doesn't. > > - Using Ubuntu 12.04 64 bit, Firefox 23, Nautilus 3.4.2 It might be a bug in nautilus, I have no idea what it uses to do the thumbnailing in those cases (IIRC, it will handle the fallbacks to gdk-pixbuf itself, rather than calling out to gnome-desktop, which makes sense as it would be faster).
Comment on attachment 252966 [details] [review] gs_file_read_noatime: Always return errors Pushed with a better commit message. Attachment 252966 [details] pushed as 870b672 - gs_file_read_noatime: Always return errors
All pushed out. Further bugs in thumbnailing with nautilus should be filed as a nautilus bug. nautilus doesn't use libgnome-desktop's thumbnailer when thumbnailing known image types, so it's unlikely that the bug lies here. Attachment 252967 [details] pushed as d045e36 - thumbnailer: Always print errors from gs_file_read_noatime() Attachment 252968 [details] pushed as fef0630 - thumbnailer: Correctly check for errors Attachment 252969 [details] pushed as 1e28ad9 - thumbnailer: Check gdk_pixbuf_loader_close()'s retval
hadess: This seems to have created a crasher regression: see bug 708435, bug 708417.