From Bugzilla Helper: User-Agent: Mozilla/5.0 Galeon/1.2.11 (X11; Linux i686; U;) Gecko/20030720 Description of problem: If I add an attachment to a new message the attachment area appears, but there is no icon or text for the attachment. (evolution:20955): GdkPixbuf-CRITICAL **: file gdk-pixbuf-io.c: line 729 (gdk_pixbuf_new_from_file): assertion `filename != NULL' failed (evolution:20955): GnomeUI-CRITICAL **: file gnome-icon-list.c: line 1219 (gnome_icon_list_append_pixbuf): assertion `im != NULL' failed Version-Release number of selected component (if applicable): evolution-1.4.4-3 How reproducible: Always Steps to Reproduce: 1. Start Evolution 2. Click New on the Toolbar 3. Click Attach 4. Select a file 5. Click OK Actual Results: The attachment area appears, but there is no icon or text for the attachment. Expected Results: The attachment area appears, and there is an icon and text for the attachment. Additional info: I tried rebuilding evolution-1.4.4-3 against the latest rawhide, but it didn't help.
I tried downgrading libgnomecanvas, but it had no effect.
The same happens in 1.4.4-4. Fact is though that when attaching jpeg pictures (don't know if it's just jpeg or also other picture formats) theire miniatures are shown as they should.
*** Bug 103525 has been marked as a duplicate of this bug. ***
I tried to add a bz2'd tarball, with an strace running, and saw that icons named "gnome-compressed" are being looked for in /usr/share/pixmaps and other likely places, and they aren't there, so the error gets thrown. Similarly named icons appear in unexamined places like: /usr/share/pixmaps/nautilus/Bluecurve/gnome-compressed.png /usr/share/icons/HighContrastLargePrint/48x48/mimetypes/gnome-compressed.png /usr/share/icons/HighContrastLargePrintInverse/48x48/mimetypes/gnome-compressed.png I think the root cause is likely to be a bug with gnome-vfs, libgnomeui, or bluecurve, although I haven't done the code dive needed to be sure. Either gnome-vfs or libgnomeui is supposed to "know" where these icons are, or Bluecurve was supposed to tell it. Hopefully someone else with more experience in the relevent code'll know where to look. I'm not sure about this - a report on rhl-beta-list says that the issue is fixed in the latest Ximian development snapshot. I don't know if the reporter's getting other packages from there or not. Anyway, the relevent strace excerpt: open("/usr/share/mime-info/gnome-vfs.keys", O_RDONLY|O_LARGEFILE) = 49 fstat64(49, {st_mode=S_IFREG|0644, st_size=1242738, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xbf24a000 read(49, "# This file contains human-reada"..., 16384) = 16384 #... reads in gnome-vfs.keys, including a key that references "gnome-compressed" #...Lots of apparent hunting after mime info... close(49) = 0 munmap(0xbf24a000, 4096) = 0 close(48) = 0 time(NULL) = 1062453392 time(NULL) = 1062453392 time(NULL) = 1062453392 access("/usr/share/pixmaps/gnome-compressed", F_OK) = -1 ENOENT (No such file or directory) access("/usr/share/pixmaps/nautilus/gnome-compressed", F_OK) = -1 ENOENT (No such file or directory) access("/usr/share/pixmaps/mc/gnome-compressed", F_OK) = -1 ENOENT (No such file or directory) access("/usr/share/pixmaps/gnome-unknown.png", F_OK) = -1 ENOENT (No such file or directory) getpid() = 12201 write(2, "\n(evolution:12201): GdkPixbuf-CR"..., 138) = 138 getpid() = 12201 write(2, "\n(evolution:12201): GnomeUI-CRIT"..., 138) = 138 As an aside, I don't know if evolution can get enough feedback to be able to decide to show a different icon or not. I think somewhere along the chain, a default icon of some kind is needed, or at least just the text of the attachment name.
Oh yeah - if I put a symlink from /usr/share/pixmaps/nautilus/Bluecurve/gnome-compressed.png to /usr/share/pixmaps/nautilus/gnome-compressed.png, the attachment icon is displayed just fine from Evolution. I imagine it would be the same for other MIME types.
Hmm. I should have looked at this a little more. evolution-1.4.4/composer/e-msg-composer-attachment-bar.c, contains pixbuf_for_mime_type(), which has some hardcoded search paths in it to find the names of the relevant icons. It was generating all of the icon file lookups directly - this didn't have anything to do with libgnomeui, except that it was passing a NULL file handle to it, big surprise... I dunno if the packaging problem is with evolution or not - I don't know if those icon locations are guaranteed or not. Anyway, there's a report on rhl-beta-list that the latest evolution devel snapshot fixes the problem. I can see that an interesting change occurred some time back to get rid of the evolution function that was doing the icon hunt in e-msg-composer-attachment-bar.c, and replaced it with a new implementation: 1.68 <danw> 2003-07-03 08:29 * e-msg-composer-attachment-bar.c (pixbuf_for_mime_type): Gone. (update): Use e_icon_for_mime_type instead. http://cvs.gnome.org/lxr/source/evolution/composer/e-msg-composer-attachment-bar.c#308 I'm having the damndest time locating the new code - GNOME anoncvs is down, GNOME LXR isn't working at all as near as I can tell, and ftp.ximian.com has the binary snapshot, but no source as far as I can see. Unless I can find the code, I'll leave this to someone with better GNOME CVS connectivity than I.
Created attachment 94135 [details] fixes from evolution HEAD, not quite right though Dan Winship checked in a nice reimplementation of the icon lookup code into HEAD. In the case where no icon is found, it uses an empty icon, rather than a NULL pointer, which at least allows the textual note to show up. There's a configure.in change to look for the libgnomeui feature for icon lookup from the icon theme, but the compile flag needed to enable the code doesn't seem to get generated with my patch, even if I manually run autoconf. AC_CHECK_HEADERS(libgnomeui/gnome-icon-lookup.h) is the line, either I've done the patch wrong, or by itself it isn't sufficient to generate the HAVE_LIBGNOMEUI_GNOME_ICON_LOOKUP_H constant needed in e-util/e-gui-utils.c. In any case, I've spent as much time on this as I can for the week.
You have to run autoheader also. Applied the patch and am building 1.4.4-5 and it works for me. Thanks for tracking this one down.
Cool! My ability to use auto* just went up by a leap and bound - thanks for the tip.
with fedora core test2 (evolution-1.4.4-7), .tif attachements aren't displayed.