6 replaced http://unix.stackexchange.com/ with https://unix.stackexchange.com/
source | link

A link to a “similar question” (http://unix.stackexchange.com/questions/77136/xdg-open-default-applications-behaviorxdg-open default applications behavior – not obviously related, but some experimentation showed that the behaviour is indeed equivalent to the one of xdg-open) led me deeper down the rabbit hole. While Firefox does not rely on, or inherit rules from, xdg-open, it uses the MIME specification files just as xdg-open does.

On a user basis, the MIME opening behaviour is configured by the specification file ~/.local/share/applications/mimeapps.list.

For me, this file contains just a few reasonable protocols and HTML (and similar) files connected to userapp-Firefox-??????.desktop, but you could easily add a line like

application/pdf=evince.desktop

to solve that problem on a per-user basis. If the file does not exist yet, make sure to add a section header, such as

[Default Applications]
application/pdf=evince.desktop

Deeper down, the mime types are defined in /usr/local/share/applications/mimeinfo.cache (this may be /usr/share/… if you are not on a FreeBSD system), which does list application/pdf=inkscape.desktop;evince.desktop;. Both evince.desktop and inkscape.desktop in that folder contain MimeType=[…]application/pdf;[…].

The mimeinfo.cache is automatically generated from the mime types listed in the .desktop files without any well-defined order, so you will have to either remove the PDF mime type from Inkscape and regenerate the cache using update-mime-database, or generate a mimeapps.list (either globally in /usr/local/share/applications/, or for your user in ~/.local/share/applications/mimeapps.list).

A link to a “similar question” (http://unix.stackexchange.com/questions/77136/xdg-open-default-applications-behavior – not obviously related, but some experimentation showed that the behaviour is indeed equivalent to the one of xdg-open) led me deeper down the rabbit hole. While Firefox does not rely on, or inherit rules from, xdg-open, it uses the MIME specification files just as xdg-open does.

On a user basis, the MIME opening behaviour is configured by the specification file ~/.local/share/applications/mimeapps.list.

For me, this file contains just a few reasonable protocols and HTML (and similar) files connected to userapp-Firefox-??????.desktop, but you could easily add a line like

application/pdf=evince.desktop

to solve that problem on a per-user basis. If the file does not exist yet, make sure to add a section header, such as

[Default Applications]
application/pdf=evince.desktop

Deeper down, the mime types are defined in /usr/local/share/applications/mimeinfo.cache (this may be /usr/share/… if you are not on a FreeBSD system), which does list application/pdf=inkscape.desktop;evince.desktop;. Both evince.desktop and inkscape.desktop in that folder contain MimeType=[…]application/pdf;[…].

The mimeinfo.cache is automatically generated from the mime types listed in the .desktop files without any well-defined order, so you will have to either remove the PDF mime type from Inkscape and regenerate the cache using update-mime-database, or generate a mimeapps.list (either globally in /usr/local/share/applications/, or for your user in ~/.local/share/applications/mimeapps.list).

A link to a “similar question” (xdg-open default applications behavior – not obviously related, but some experimentation showed that the behaviour is indeed equivalent to the one of xdg-open) led me deeper down the rabbit hole. While Firefox does not rely on, or inherit rules from, xdg-open, it uses the MIME specification files just as xdg-open does.

On a user basis, the MIME opening behaviour is configured by the specification file ~/.local/share/applications/mimeapps.list.

For me, this file contains just a few reasonable protocols and HTML (and similar) files connected to userapp-Firefox-??????.desktop, but you could easily add a line like

application/pdf=evince.desktop

to solve that problem on a per-user basis. If the file does not exist yet, make sure to add a section header, such as

[Default Applications]
application/pdf=evince.desktop

Deeper down, the mime types are defined in /usr/local/share/applications/mimeinfo.cache (this may be /usr/share/… if you are not on a FreeBSD system), which does list application/pdf=inkscape.desktop;evince.desktop;. Both evince.desktop and inkscape.desktop in that folder contain MimeType=[…]application/pdf;[…].

The mimeinfo.cache is automatically generated from the mime types listed in the .desktop files without any well-defined order, so you will have to either remove the PDF mime type from Inkscape and regenerate the cache using update-mime-database, or generate a mimeapps.list (either globally in /usr/local/share/applications/, or for your user in ~/.local/share/applications/mimeapps.list).

5 Section header is important
source | link

A link to a “similar question” (http://unix.stackexchange.com/questions/77136/xdg-open-default-applications-behavior – not obviously related, but some experimentation showed that the behaviour is indeed equivalent to the one of xdg-open) led me deeper down the rabbit hole. While Firefox does not rely on, or inherit rules from, xdg-open, it uses the MIME specification files just as xdg-open does.

On a user basis, the MIME opening behaviour is configured by the specification file ~/.local/share/applications/mimeapps.list.

For me, this file contains just a few reasonable protocols and HTML (and similar) files connected to userapp-Firefox-??????.desktop, but you could easily add a line like

application/pdf=evince.desktop

to solve that problem on a per-user basis. If the file does not exist yet, make sure to add a section header, such as

[Default Applications]
application/pdf=evince.desktop

Deeper down, the mime types are defined in /usr/local/share/applications/mimeinfo.cache (this may be /usr/share/… if you are not on a FreeBSD system), which does list application/pdf=inkscape.desktop;evince.desktop;. Both evince.desktop and inkscape.desktop in that folder contain MimeType=[…]application/pdf;[…].

The mimeinfo.cache is automatically generated from the mime types listed in the .desktop files without any well-defined order, so you will have to either remove the PDF mime type from Inkscape and regenerate the cache using update-mime-database, or generate a mimeapps.list (either globally in /usr/local/share/applications/, or for your user in ~/.local/share/applications/mimeapps.list).

A link to a “similar question” (http://unix.stackexchange.com/questions/77136/xdg-open-default-applications-behavior – not obviously related, but some experimentation showed that the behaviour is indeed equivalent to the one of xdg-open) led me deeper down the rabbit hole. While Firefox does not rely on, or inherit rules from, xdg-open, it uses the MIME specification files just as xdg-open does.

On a user basis, the MIME opening behaviour is configured by the specification file ~/.local/share/applications/mimeapps.list.

For me, this file contains just a few reasonable protocols and HTML (and similar) files connected to userapp-Firefox-??????.desktop, but you could easily add a line like

application/pdf=evince.desktop

to solve that problem on a per-user basis.

Deeper down, the mime types are defined in /usr/local/share/applications/mimeinfo.cache (this may be /usr/share/… if you are not on a FreeBSD system), which does list application/pdf=inkscape.desktop;evince.desktop;. Both evince.desktop and inkscape.desktop in that folder contain MimeType=[…]application/pdf;[…].

The mimeinfo.cache is automatically generated from the mime types listed in the .desktop files without any well-defined order, so you will have to either remove the PDF mime type from Inkscape and regenerate the cache using update-mime-database, or generate a mimeapps.list (either globally in /usr/local/share/applications/, or for your user in ~/.local/share/applications/mimeapps.list).

A link to a “similar question” (http://unix.stackexchange.com/questions/77136/xdg-open-default-applications-behavior – not obviously related, but some experimentation showed that the behaviour is indeed equivalent to the one of xdg-open) led me deeper down the rabbit hole. While Firefox does not rely on, or inherit rules from, xdg-open, it uses the MIME specification files just as xdg-open does.

On a user basis, the MIME opening behaviour is configured by the specification file ~/.local/share/applications/mimeapps.list.

For me, this file contains just a few reasonable protocols and HTML (and similar) files connected to userapp-Firefox-??????.desktop, but you could easily add a line like

application/pdf=evince.desktop

to solve that problem on a per-user basis. If the file does not exist yet, make sure to add a section header, such as

[Default Applications]
application/pdf=evince.desktop

Deeper down, the mime types are defined in /usr/local/share/applications/mimeinfo.cache (this may be /usr/share/… if you are not on a FreeBSD system), which does list application/pdf=inkscape.desktop;evince.desktop;. Both evince.desktop and inkscape.desktop in that folder contain MimeType=[…]application/pdf;[…].

The mimeinfo.cache is automatically generated from the mime types listed in the .desktop files without any well-defined order, so you will have to either remove the PDF mime type from Inkscape and regenerate the cache using update-mime-database, or generate a mimeapps.list (either globally in /usr/local/share/applications/, or for your user in ~/.local/share/applications/mimeapps.list).

4 Edit a comment in, and generally clear up
source | link

A link to a “similar question” (http://unix.stackexchange.com/questions/77136/xdg-open-default-applications-behavior – not obviously related, but some experimentation showed that the behaviour is indeed dictated byequivalent to the one of xdg-open) led me deeper down the rabbit hole: It appears that. While Firefox inherits its default file opening behaviour in some casesdoes not rely on, or inherit rules from, xdg-open, which in my case does open PDFit uses the MIME specification files with Inkscapejust as xdg-open does. A local configuration file for that program

On a user basis, the MIME opening behaviour is configured by the specification file ~/.local/share/applications/mimeapps.list.

For me, this file contains just a few reasonable protocols and HTML (and similar) files connected to userapp-Firefox-??????.desktop, but you could easily add a line like

application/pdf=evince.desktop

to solve that problem on a per-user basis.

Deeper down, the mime types are defined in /usr/local/share/applications/mimeinfo.cache (this may be /usr/share/… if you are not on a FreeBSD system), which does listslist application/pdf=inkscape.desktop;evince.desktop;. Both evince.desktop and inkscape.desktop in that folder contain MimeType=[…]application/pdf;[…].

The mimeinfo.cache is automatically generated from the mime types listed in the .desktop files without any well-defined order, so you will have to either remove the PDF mime type from Inkscape and regenerate the cache using update-mime-database, or generate a mimeapps.list (either globally in /usr/local/share/applications/, or for your user in ~/.local/share/applications/mimeapps.list).

A link to a “similar question” (http://unix.stackexchange.com/questions/77136/xdg-open-default-applications-behavior – not obviously related, but some experimentation showed that the behaviour is indeed dictated by xdg-open) led me deeper down the rabbit hole: It appears that Firefox inherits its default file opening behaviour in some cases from xdg-open, which in my case does open PDF files with Inkscape. A local configuration file for that program is ~/.local/share/applications/mimeapps.list.

For me, this file contains just a few reasonable protocols and HTML (and similar) files connected to userapp-Firefox-??????.desktop, but you could easily add a line like

application/pdf=evince.desktop

to solve that problem on a per-user basis.

Deeper down, the mime types are defined in /usr/local/share/applications/mimeinfo.cache (this may be /usr/share/… if you are not on a FreeBSD system), which does lists application/pdf=inkscape.desktop;evince.desktop;. Both evince.desktop and inkscape.desktop in that folder contain MimeType=[…]application/pdf;[…].

The mimeinfo.cache is automatically generated from the mime types listed in the .desktop files without any well-defined order, so you will have to either remove the PDF mime type from Inkscape and regenerate the cache using update-mime-database, or generate a mimeapps.list (either globally in /usr/local/share/applications/, or for your user in ~/.local/share/applications/mimeapps.list.

A link to a “similar question” (http://unix.stackexchange.com/questions/77136/xdg-open-default-applications-behavior – not obviously related, but some experimentation showed that the behaviour is indeed equivalent to the one of xdg-open) led me deeper down the rabbit hole. While Firefox does not rely on, or inherit rules from, xdg-open, it uses the MIME specification files just as xdg-open does.

On a user basis, the MIME opening behaviour is configured by the specification file ~/.local/share/applications/mimeapps.list.

For me, this file contains just a few reasonable protocols and HTML (and similar) files connected to userapp-Firefox-??????.desktop, but you could easily add a line like

application/pdf=evince.desktop

to solve that problem on a per-user basis.

Deeper down, the mime types are defined in /usr/local/share/applications/mimeinfo.cache (this may be /usr/share/… if you are not on a FreeBSD system), which does list application/pdf=inkscape.desktop;evince.desktop;. Both evince.desktop and inkscape.desktop in that folder contain MimeType=[…]application/pdf;[…].

The mimeinfo.cache is automatically generated from the mime types listed in the .desktop files without any well-defined order, so you will have to either remove the PDF mime type from Inkscape and regenerate the cache using update-mime-database, or generate a mimeapps.list (either globally in /usr/local/share/applications/, or for your user in ~/.local/share/applications/mimeapps.list).

3 The actual top “similar question” I followed was this one, even though the previously edited in one looks more relevant
source | link
2 added 103 characters in body
source | link
1
source | link