GNOME Bugzilla – Bug 669936
gio does not return the default application chosen by the user
Last modified: 2012-11-09 14:39:05 UTC
When I use Firefox (build with --enable-gio) or Epipĥany with KDE4, they don't use the default application I chosen.
eg. if I choose to use okular to view pdf files in KDE4 systemsettings,
firefox, thunderbird or epiphany still uses evince by default to read pdf.
This is working fine with gio 2.28.6 (Mageia 1: Firefox 10.0.1 & gio 2.28.6).
This isn't working with gio 2.31.16 (current Mageia Cauldron), and gio 2.30.1 (OpenSuse 12.1 KDE4 LiveCD).
As it's working fine with previous release, I think it's a regression with recent release of gio library.
with this mimeapps.list, Firefox propose to read pdf files with evince when using gio 2.31.16 or 2.30.1, which is wrong.
cf. freedesktop.org mime-actions-spec specifications
"User-specified application ordering
Users can change the default order of applications by writing (using graphical tools, of course) into the file ~/.local/share/applications/mimeapps.list
The syntax of this file is:
This means that foo1 is the preferred application for mimetype1, but if it is not installed then foo2 is going to be used, etc. "
I confirm this.
I actually wanted to report similar issue with thunar, which uses gio as a backend.
freedesktop.org mime-actions-spec specification is not honored in gio.
If you choose an default application for some file via Thunar, it will be written to the end of the list, instead of the beginning as the spec suggests.
I was redirected here from xfce bug tracker
My original report is here:
Try gvfs-mime --query application/pdf
Here is what I see:
$ gvfs-mime --query application/pdf
Default application for 'application/pdf': evince.desktop
The Default application line is what causes firefox to choose evince.
Changing the order in the Added Associations line for application/pdf doesn't change that. What helps is to add
[Default Applications] is not in the mime-action-spec, it should not exist in mimeapps.list
It definitively was discussed on the list. Quite possible that it hasn't made it back into the written spec. But that is not a GLib bug.
Could you point me to the discussion, please?