GNOME Bugzilla – Bug 329072
gnomevfs-info doesn't recognize image/x-pcx files
Last modified: 2007-02-23 10:24:50 UTC
Ghtumb doesn't display PCX image files thumbnails in folders as default (until I turn on "Determine image type from content" in preferences) Steps to reproduce: 1. Put image, attached to this bugreport, in any folder 2. Start gthumb, press on "Folders" button and go to folder, where you put attached image Current results: Ghtumb doesn't display attached PCX image file thumbnail in folder as default (until I turn on "Determine image type from content" in preferences and press View->Reload) Expected results: Ghumb should display attached image thumbnail in right side, where all other images thumbnails are displayed even when "Determine image type from content" is turned off.
it's likely that the pcx images do not have the right extention.
(In reply to comment #1) > it's likely that the pcx images do not have the right extention. It is not so - PCX image has the right extention: mantas@manto-kompas:~/Desktop$ file pic06334.pcx pic06334.pcx: PCX ver. 3.0 image data bounding box [0, 0] - [691, 283], 8-bit colour, RLE compressed I'm attaching this pcx image to this bugreport, maybe this can help you.
Created attachment 59758 [details] PCX image, which thumbnail Gthumb doesn't display as default
I think it's a bug in gnome-vfs, because gnome_vfs_mime_type_from_name_or_default does not return the right mime type. changing product to gnome-vfs...
Confirming, reassigning to gThumb, which is not registered for the "image/x-pcx" MIME type.
Created attachment 73144 [details] [review] Patch to add image/pcx to app registry, etc The patches adds "image/pcx" wherever "image/png" is found in the source code, and fixes the numeric parameter of bonobo_persist_generate_content_types in components/image-viewer/viewer-stream.c. Please review/commit.
Adding image/x-pcx to data/gthumb.desktop.in and data/gthumb.applications makes no difference whatsoever. As Paolo said, gthumb sees these files, and tests them with gnome_vfs_mime_type_from_name_or_default or gnome_vfs_get_file_mime_type. Both of these functions are returning "application/octet-stream", even though Nautilus is reporting image/x-pcx. Something is wrong in gnome_vfs. Reassigning to gnome_vfs, again. - Mike
Additional details - Nautilus says: /eraseme/test.pcx = image/x-pcx xdg-mime says: /eraseme/test.pcx = application/octet-stream Nautilus says: ssh://localhost/eraseme/test.pcx = application/octet-stream In other words, Nautilus reports the mime-type of LOCAL pcx files properly. It mis-reports gnome-vfs remote pcx files. xdg-mime gets it wrong for local files. (It doesn't support remote ones). So this is definitely not a gThumb bug... - Mike
I've reported this issue here: https://bugs.freedesktop.org/show_bug.cgi?id=10032 - Mike
Ack, I didn't realize xdg-mime was just a wrapper for gnome-vfs functions. Anyway, more info: [root@flay ~]# gnomevfs-info /fileserver/mjcfiles/eraseme/test.pcx Name : test.pcx Type : Regular MIME type : application/octet-stream [root@flay ~]# file /fileserver/mjcfiles/eraseme/test.pcx /fileserver/mjcfiles/eraseme/test.pcx: PCX ver. 3.0 image data bounding box [1, 1] - [949, 305], 8-bit image, 151 x 151 dpi, RLE compressed - Mike
I've patched gthumb to work around this issue - it checks for a pcx extension if application/octet-stream is reported (it already check binary data for raw/hdr photo types). - Mike
The "image/x-pcx" MIME type does not have an associated glob pattern, I've filed a bug report in the freedesktop bugzilla. It would be great if somebody could try to get some info on the MIME types that lack a glob pattern: https://bugs.freedesktop.org/show_bug.cgi?id=10072 Resolving as NOTGNOME, feel to keep the workaround in gThumb for now.