Bug 58927 - update-desktop-database ignores subdir kde4 in /usr/share/applications
Summary: update-desktop-database ignores subdir kde4 in /usr/share/applications
Status: RESOLVED NOTOURBUG
Alias: None
Product: desktop-file-utils
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium major
Assignee: Vincent Untz
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-01-01 23:33 UTC by Mariusz Fik
Modified: 2013-01-07 13:41 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Description Mariusz Fik 2013-01-01 23:33:11 UTC
It seems update-desktop-database ignores kde4 subdir in /usr/share/applications and produced mimeinfo.cache has wrong format. For example, I have a desktop file:

/usr/share/applications/kde4/okularApplication_pdf.desktop

which contains configured MimeTypes:

MimeType=application/pdf;application/x-gzpdf;application/x-bzpdf;application/x-wwf;

Now, update-desktop-database produces list of applications supporting 'application/pdf':

application/pdf=gimp.desktop;gimp.desktop;kde4-okularApplication_pdf.desktop;

But second entry, for okular is wrong. It has incorrect .desktop file name and also should be as first in that list.

If any additional info is required, please post request for it ;)


openSUSE 12.2 with desktop-file-utils-0.20

Regards,
Mariusz Fik
Comment 1 Vincent Untz 2013-01-07 07:47:34 UTC
The name is not wrong, but based on what the menu specification says:

"""If the directory contains sub-directories then these sub-directories should be (recursively) scanned as well. The name of the subdirectory should be added as prefix to the desktop-file id together with a dash character ("-") So given a <AppDir> /foo/bar and desktop entry /foo/bar/booz/Hello.desktop the desktop entry would get a desktop-file id of booz-Hello.desktop A desktop entry /foo/bar/bo/oz/Hello.desktop would result in a desktop-file id of bo-oz-Hello.desktop"""

(http://specifications.freedesktop.org/menu-spec/menu-spec-latest.html)

Also, why should it be first? The order in mimeinfo.cache is not representative of any priority.
Comment 2 Vincent Untz 2013-01-07 08:05:13 UTC
For the record, I fixed the bug that made gimp.desktop appear twice.
Comment 3 Mariusz Fik 2013-01-07 13:19:35 UTC
Maybe not first, but at least gimp should have lower priority then default desktop viewer. In case KDE desktop, okular is default pdf viewer, Gnome has evince, xfce recommends ePDFView.

In my case, with KDE desktop, opera can't find proper .desktop file.
`strace -e trace=open,access -o opera_access.log /usr/bin/opera` gives me:

open("/usr/share/applications/kde4-okularApplication_pdf.desktop", O_RDONLY) = -1 ENOENT (No such file or directory)

And that's true, there is no such file. Then maybe it's a problem with opera?
Comment 4 Vincent Untz 2013-01-07 13:41:07 UTC
(In reply to comment #3)
> Maybe not first, but at least gimp should have lower priority then default
> desktop viewer.

Again, mimeinfo.cache has nothing to do with the priority with which an app is chosen for handling a mime type. For instance, in GNOME, the default handler for a mime type is defined in /usr/share/applications/defaults.list and I suspect KDE has a similar mechanism.

> In my case, with KDE desktop, opera can't find proper .desktop file.
> `strace -e trace=open,access -o opera_access.log /usr/bin/opera` gives me:
> 
> open("/usr/share/applications/kde4-okularApplication_pdf.desktop", O_RDONLY)
> = -1 ENOENT (No such file or directory)
> 
> And that's true, there is no such file. Then maybe it's a problem with opera?

Yes, that would be a bug in Opera, I'd argue. They should try kde4/okularApplication_pdf.desktop if kde4-okularApplication_pdf.desktop fails.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.