I'm using xdg-utils 1.0 which was in Ubuntu 8.04 Actually i was learning how to specify the default application used for different formats, and then i found xdg-utils. It is really very useful. But there's sth i found strange: in ~/.local/share/applications/defaults.list ~/.local/share/applications/mimeinfo.cache it wrote like this: application/pdf=/opt/Adobe/Reader8/Resource/Support/AdobeReader.desktop in /usr/local/share/applications/defaults.list /usr/local/share/applications/mimeinfo.cache it wrote like this: application/pdf=evince.desktop;/opt/Adobe/Reader8/Resource/Support/AdobeReader.desktop And then i try these: $ xdg-mime query default application/pdf /opt/Adobe/Reader8/Resource/Support/AdobeReader.desktop which means the config in .local will override the one in /usr/local/share but when i use $ xdg-open some-file.pdf evince will come up. It's really a weird thing since double-cliking on pdf file in Nautilus will surely trigger Adobe Reader. I tried other formats, such as text/xml, and it seems the config of this in .local will override the one in /usr/local/share, which is known as behaving normally. I don't know if this is a bug of xdg-utils or AdobeReader, so if more infomation is needed, plz let me know. Thanks.
This affects Chromium, which relies on xdg-open to open files.
Is this in gnome? those values in defaults.list look correct to me, so if your DE isn't respecting that, the bug seems to lie not in xdg-utils. For example, does gvfs-open <file> or gnome-open <file> do the same thing?
Sorry, I should've linked to the bug report: http://code.google.com/p/chromium/issues/detail?id=38827 I haven't reproduced this myself. The reporter claims that their system doesn't know how to open PDFs. $ xdg-mime query default application/pdf AdobeReader.desktop then "using xdg-open indeed opens the old viewer and not Adobe Reader. I'm completely unfamiliar with xdg-open, so I don't know to explain the difference between the 'xdg-mime query default application/pdf' result and 'xdg-open myfile.pdf'"
(In reply to comment #2) Hi, I'm the one that reported the Chromium bug. > Is this in gnome? Yes. > those values in defaults.list look correct to me, so if your DE isn't > respecting that, the bug seems to lie not in xdg-utils. > > For example, does > > gvfs-open <file> > > or > > gnome-open <file> > > do the same thing? I don't have gvfs-open on my machine. gnome-open opens the old viewer and not Adobe Reader.
So is the fix for us to check first if you have gvfs-open installed and then error out before calling xdg-open? That sounds pretty ugly; better suggestions are welcome. :)
gnome-open should work too, and I *thought* it followed the xdg spec here... could be a gnome-open bug. I'll have to do some experimenting. For posterity, what version of gnome-open do you have installed?
I cannot reproduce this problem on a recent fedora (12, 13) install, both gnome-open and gvfs-open properly respect items listed in ~/.local/share/applications/defaults.list
Tested on rhel5 too, $ rpm -q -f /usr/bin/gnome-open libgnome-2.16.0-6.el5.x86_64 and it works as advertised here too. though, I'm starting to think it's the full path that's not working here. using, /opt/Adobe/Reader8/Resource/Support/AdobeReader.desktop let me double-check the .desktop spec here, I'm suspecting that .desktop files need to be discoverable via $XDG_DATA_DIRS
boo, from my reading I think I've concluded 2 things 1. full paths are indeed not supported (from what I can tell so far) 2. we need to add support for mimeapps.list , see http://www.freedesktop.org/wiki/Specifications/mime-actions-spec
(In reply to comment #6) > gnome-open should work too, and I *thought* it followed the xdg spec here... > could be a gnome-open bug. I'll have to do some experimenting. > > For posterity, what version of gnome-open do you have installed? $ gnome-open --version GNOME gnome-url-show 2.22.0
based on comment #9 , and the use of full paths here (outside of $XDG_DATA_DIRS) not being supported by the spec, marking as NOTABUG
What is the reasoning behind not supporting full paths in the spec? It sounds like a completely valid request to me, and very easily supported (test if path starts with a /).
xdg-utils maintainers aren't in charge of the specification, good question though.
I'm reopening this bug and moving it to a more appropriate product. CC Bastien, I'd like a confirmation on whether full paths is something we would want to support in the future.
The spec is tracked elsewhere, moving.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xdg/desktop-file-utils/issues/41.
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.