Here's the scoop. When thunar_vfs_mime_database_store_parse_file loads mimeinfo.cache, it calls thunar_vfs_mime_database_get_info_locked to get an I.D. for each MIME-type entry in the file. thunar_vfs_mime_database_get_info_locked "unaliases" some of these type names; for example, it changes image/pjpeg to image/jpeg. As a result, thunar_vfs_mime_database_store_parse_file creates two entries for image/jpeg in Thunar's database -- the original image/jpeg entry and the one that was image/pjpeg. When thunar_vfs_mime_database_get_applications goes to find programs that can open a JPEG file, it reads only one of those entries (the one that came last in mimeinfo.cache, as it happens).
Thus when the image/pjpeg entry comes after image/jpeg in mimeinfo.cache, programs that can load normal JPEG's but not progressive ones are not shown. As I see it, there are three ways to fix this behavior. The easiest is to leave out the unaliasing code altogether, but this may have consequences that I'm not aware of). The second is for thunar_vfs_mime_database_store_parse_file to merge entries with duplicate MIME types. The third is for thunar_vfs_mime_database_get_applications to be prepared to read duplicate entries. I don't think this last solution is practical since we would have to abandon g_hash_table_lookup and look up matching entries in the database some other way. Simply removing image/pjpeg from the unaliasing would not really fix the problem as it would still potentially occur for other file types. Any thoughts? -- John Lindgren -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
