Bug#678510: gvfs-open calls audacious when opening an smb share

[chrysn]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20121113/e19ce17e/attachment.pgp>