GNOME Bugzilla – Bug 731636
Application order in context menu is wrong
Last modified: 2014-10-04 18:01:21 UTC
I'm using PCManFM 1.2.0 as filemanager and after upgrading GLib from version 2.40.0 to version 2.41.0 I'm noticing that the application order in the context menu of PCManFM isn't correct anymore. Here is a testcase: /usr/local/share/applications/defaults.list contains: [Default Applications] text/plain=SciTE.desktop; /usr/local/share/applications/test.desktop contains: [Desktop Entry] Exec=true MimeType=text/plain; Name=Test NoDisplay=true Type=Application On executing "update-desktop-database" /usr/local/share/applications/mimeinfo.cache is created and contains: [MIME Cache] text/plain=test.desktop; With this testcase normally SciTE should be at the first position and Test on the second. But with GLib 2.41.0 they have the opposite order while GLib 2.40.0 is working fine.
Here is the link to the PCManFM ticket: https://sourceforge.net/p/pcmanfm/bugs/880/
Just as a sidenote from PCManFM developer: that context menu applications list is retrieved using g_app_info_get_all_for_type() API. I hope that would help you to create a testcase code. Cheers!
This is because of a change in the mimeapps spec. "Default application" no longer determines the ordering in the menu, which is supposed to be based only on most-recently-used now. If you want the default first, you should put it there yourself. See http://standards.freedesktop.org/mime-apps-spec/mime-apps-spec-latest.html
Ah, this explains the different order. But I have noticed another problem: /usr/share/applications/defaults.list has the line "application/pdf=evince.desktop" and many other lines from installed packages. /usr/share/applications/mimeinfo.cache has the line "application/pdf=gimp.desktop;evince-previewer.desktop;evince.desktop;" and many other lines from installed packages. /usr/local/share/applications/defaults.list has no application/pdf entry. /usr/local/share/applications/mimeinfo.cache has the line "application/pdf=convert_pdf.desktop;" and a few other lines. Normally I would expect that a double click in the file manager on a PDF file would open it with evince and that evince is at least somewhere in the context menu. This is the case with GLib 2.40.0 but with GLib 2.41.0 a doubleclick does trigger convert_pdf.desktop and evince is not listed on the context menu.
In order to be certain about double-click action: it is handled in PCManFM (and I suppose in other file managers that use GLib, as well) using application returned by g_app_info_get_default_for_type() API.
After reading the linked specification I'm noticing that there is no defaults.list anymore and that it says that default applications should go into mimeapps.list. Are entries in the defaults.list now invalid? If yes I should make a report against all Ubuntu packages writing into defaults.list to get this fixed.
defaults.list was only ever a GNOME-specific file. GIO continues to read this file as a fallback to mimeapps.list, but it should be considered deprecated. Since this file was only ever used by GNOME we decided to refrain from mentioning it in the new (cross-desktop) spec. Is it possible that PCManFM is querying the list of all apps for the filetype and treating the first-returned as if it were the default? That would be consistent with what you describe, and it would also match the expected behaviour of GIO (as of the changes). On the other hand, g_app_info_get_default_for_type() absolutely should be returning evince in the scenario you describe. There is a small program in glib/gio/tests calls "apps". It is built as part of the test suite and you can run it with various commandline options in order to query the mime system (and other aspects of GAppInfo). Some things to try: ./apps default-for-type application/pdf ./apps recommended-for-type application/pdf ./apps all-for-type application/pdf I'd expect the first one to report "evince" and the others to report convert_pdf at the front of the list with other apps, including evince, further down. The reason that convert_pdf is preferentially treated is because it is installed at a "higher level" in /usr/local. It is possible to use ~/.config/mimeapps.list to override this ordering (since the user's config is treated as the highest level of all).
As I've written already, in LibFM/PCManFM the list is retrieved using g_app_info_get_all_for_type() while default is from g_app_info_get_default_for_type() API. Default app is never used in list.
I have now compiled GLib 2.41.0 with the testsuite and this is the result: sworddragon@ubuntu:~/tmp/glib-2.41.0/gio/tests$ ./apps default-for-type application/pdf convert_pdf.desktop sworddragon@ubuntu:~/tmp/glib-2.41.0/gio/tests$ ./apps recommended-for-type application/pdf convert_pdf.desktop display.im6.desktop sworddragon@ubuntu:~/tmp/glib-2.41.0/gio/tests$ ./apps all-for-type application/pdf convert_pdf.desktop display.im6.desktop
I've been testing this as well and there is indeed some strange behaviour here. I'll look into it tomorrow (and hopefully write some better testcases while I'm at it).
After testing this with GLib 2.42.0 this bug seems to be fixed (it seems already to be fixed in later versions of GLib 2.41.x). I'm seeing now all entries in the context menu and opening a file does now open the correct default application. The only thing I'm noticing is that entries only in [Default Applications] doesn't appear in the context menu but I'm currently assuming that this is the correct behavior. If this is the case this ticket can be closed.
Sorry -- this was indeed fixed here: https://git.gnome.org/browse/glib/commit/?id=08efbda7333cf1d349719e699bbcbb63b8ef09e4 I was unable to successfully find this bug at the time, however. Thanks for the poke. Also, you must also add an application to the [Added] list, as you correctly assume.