Bug 102553 - Attachments don't show up in the attachment area while composing a new message
Attachments don't show up in the attachment area while composing a new message
Product: Red Hat Raw Hide
Classification: Retired
Component: evolution (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
: 103525 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2003-08-17 14:50 EDT by Nathan G. Grennan
Modified: 2007-04-18 12:56 EDT (History)
4 users (show)

See Also:
Fixed In Version: 1.4.4-5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-09-02 19:31:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
fixes from evolution HEAD, not quite right though (10.28 KB, patch)
2003-09-02 01:32 EDT, George Karabin
no flags Details | Diff

  None (edit)
Description Nathan G. Grennan 2003-08-17 14:50:00 EDT
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):

How reproducible:

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.
Comment 1 Nathan G. Grennan 2003-08-17 15:10:04 EDT
I tried downgrading libgnomecanvas, but it had no effect.
Comment 2 Daniel Malmgren 2003-08-24 11:41:50 EDT
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.
Comment 3 Kyle R Maxwell 2003-09-01 17:08:04 EDT
*** Bug 103525 has been marked as a duplicate of this bug. ***
Comment 4 George Karabin 2003-09-01 18:32:07 EDT
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:


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
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
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
Comment 5 George Karabin 2003-09-01 18:36:02 EDT
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.
Comment 6 George Karabin 2003-09-01 19:40:09 EDT
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.


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.

Comment 7 George Karabin 2003-09-02 01:32:16 EDT
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.
Comment 8 Jeremy Katz 2003-09-02 19:31:58 EDT
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. 
Comment 9 George Karabin 2003-09-02 20:16:22 EDT
Cool! My ability to use auto* just went up by a leap and bound - thanks for the tip.
Comment 10 Marius Andreiana 2003-10-09 16:34:38 EDT
with fedora core test2 (evolution-1.4.4-7), .tif attachements aren't displayed.

Note You need to log in before you can comment on or make changes to this bug.