After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 141580 - Changing file association prevents thumbnail generation
Changing file association prevents thumbnail generation
Status: RESOLVED FIXED
Product: nautilus
Classification: Core
Component: Thumbnails
2.6.x
Other Linux
: Normal normal
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
: 143644 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2004-05-01 16:59 UTC by marius
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: 2.5/2.6


Attachments
Patch to nautilus CVS (1.45 KB, patch)
2004-06-19 16:21 UTC, Nickolay V. Shmyrev
none Details | Review
Patch to libgnomeui (1.45 KB, patch)
2004-06-19 16:21 UTC, Nickolay V. Shmyrev
none Details | Review

Description marius 2004-05-01 16:59:59 UTC
Description of Problem:
After specifying something else as default, or
just adding another entry to the "Open With" menu
entry it refuses to generate thumbnails for that
filetype later on. Already generated thumbnails
display just fine though.

Steps to reproduce the problem:
1. Select a video file
2. Right click, select "Open with->Other
Application" then specify something. In my case
it's xine --enqueue.
3. Enter a folder with this kinda filetype that
don't have thumbnails.

Actual Results:
Just the standard video icon.

Expected Results:
Generated thumbnail.

How often does this happen? 
Everytime.

Additional Information:
Reproduced on both my laptop and my workstation
running dropline gnome 2.6 on slackware
current/slackware 9.1. Happens on both network
shares (NFS) and local shares. The size thing is
set to 1gb and should not affect this.
Deleting .gnome/ "fixes" the problem, but then all
my custom file actions are gone. As soon as I
recreate them it happens again.
Comment 1 marius 2004-05-01 17:07:16 UTC
went into ~/.gnome/mime-info/user.keys and commented out the icon_filename
properties to the affected filetype and that actually solved the problem. Still
a bug on some level though and should probably be fixed.
Comment 2 Martin Wehner 2004-06-03 19:30:22 UTC
*** Bug 143644 has been marked as a duplicate of this bug. ***
Comment 3 Martin Wehner 2004-06-03 19:33:18 UTC
Confirming & Updating summary to better reflect the issue.
Comment 4 Nickolay V. Shmyrev 2004-06-19 16:21:03 UTC
Created attachment 28861 [details] [review]
Patch to nautilus CVS
Comment 5 Nickolay V. Shmyrev 2004-06-19 16:21:27 UTC
Created attachment 28862 [details] [review]
Patch to libgnomeui
Comment 6 Nickolay V. Shmyrev 2004-06-19 16:22:27 UTC
Those are required patches to fix that problem. Unfortunately, the easiest and
more natural solution requires patching both nautilus and libgnomeui.
Comment 7 Alexander Larsson 2004-07-02 10:02:40 UTC
Hmmm, I don't like exposing the gnome-vfs mime-specific icon in the API like
that, because its currently scheduled to be removed as part of the move to a new
mime system. 

Basically, gnome_vfs_mime_get_icon will go away in Gnome 2.8, and this problem
will be solved.
Comment 8 Nickolay V. Shmyrev 2004-07-02 14:47:27 UTC
Really hope that it will be so :). 

But as you can see that problem is not related to gnome_vfs_mime_get_icon. The
problem is to give thumbnail more priority than mime icons. To do that,
gnome_icon_lookup should give a hint of what we found - image or mime icon.
Comment 9 Alexander Larsson 2004-08-12 07:55:57 UTC
They are very related, gnome_vfs_mime_get_icon is the only way you'd get an
absolute filename for the mimetype.

Anyway, this should be fixed in head now.