reassign 678510 desktop-file-utils thx > smb shares i added via gvfs wont open in my fileexplorer, but > audacious [an audio player, ed.com.] is started instead.
(other symptoms are gthumb's (image viewer) "open in file manager" menu entry launching audacious). the desktop file specification[1] only says "that an application knows how to handle" a mime type; it seems audacious can open directories and do something that's within reason for this type of application (play its audio content). for a practical example, that could be expected to be listed in an "Open with…" menu of a file browser. it is unfortunate that this causes audacious to be opened as the default mime type handler for inode/directory, but that's for lack of better default values, setting which can not be the responsibility of audacious. if no default is set, /usr/share/applications/mimeinfo.cache's inode/directory line is evaluated, and the leftmost entry is used. that file gets generated by update-desktop-database. similar problems have been seen with other applications too, eg. inkscape being the default program for pdf files (which it can open, but it's not what most users want by default). i don't hve a complete solution at hand, but a suggestion would be an additional field in desktop files (MimeTypeDefaultable or any better name) that indicates that an application thinks it would be suitable as a default handler for that mime type; update-desktop-database would then rank them higher. (naming it MimeTypePreferred or similar would not be a good idea imo because the spec emphasises that there is no priority within the mime types, which would mean what *the application prefers to handle*, not *what the application is preferred for handling*) an alternative approach would be to keep a distribution-wide list of preferred applications for common mime types (like ~/.local/share/applications/mimeapps.list), that would be fallen through if the applications are not installed, but that would be long lists that would have to be maintained centrally. re-assigning this bug to desktop-file-utils for the abovementioned reasons. if you, the desktop-file-utils maintainers, insist on a different interpretation of the desktop file spec, please assign back, but in my opinion this kind of problem better be solved once and for all. best regards chrysn [1] http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s07.html
signature.asc
Description: Digital signature