Bug 102553

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.