Just annotations of little "how to's", so I know I can find how to do something I've already done when I need to do it again, in case I don't remember anymore, which is not unlikely. Hopefully they can be useful to others, but I can't guarantee that it will work, or that it won't even make things worse.
Fixing the annoying firefox' associations issue once and for all
Posted 08-19-2011 at 03:49 PM by the dsc
Tags file association, firefox, pdf
Probably affects all gecko-derived browsers, like iceape, kazehakase, epiphany, namoroka, whatever. May be exclusively a KDE-derived problem though, I don't know.
Sometimes, for some reason, the system decides that you probably want to open downloaded PDFs, from iceweasel's/firefox' downloads window, with krita or gimp, programs that won't open PDFs at all. It's really confusing because you even have a correct, pdf-reader application set as default in other parts of the system (file managers, both KDE's and Gnome's), and you even get it from "xdg-mime query default application/pdf". Then you conclude that it must be firefox' sole fault, and you go and find some preferences related with handling files. But these will affect only how it will handle files "on the fly", files it's about to download/already cacheing, not which program will be used to open the file on the downloads window.
As it happens, linux has some apparently redundant file-association settings, firefox seems to pick a "unusual" one, whose very reason to exist may be questionable.
Here's the solution, though:
Source: http://forums.opensuse.org/english/g...ml#post1945902
I wonder how these people find out how to fix this sort of thing among all the mess that linux configuration files are.
As a sidenote, I didn't have to copy this "defaults.list" file, which does not even exist on my system (debian wheezy/sid, testing). Otherwise it works, and you don't even need to restart firefox.
Sometimes, for some reason, the system decides that you probably want to open downloaded PDFs, from iceweasel's/firefox' downloads window, with krita or gimp, programs that won't open PDFs at all. It's really confusing because you even have a correct, pdf-reader application set as default in other parts of the system (file managers, both KDE's and Gnome's), and you even get it from "xdg-mime query default application/pdf". Then you conclude that it must be firefox' sole fault, and you go and find some preferences related with handling files. But these will affect only how it will handle files "on the fly", files it's about to download/already cacheing, not which program will be used to open the file on the downloads window.
As it happens, linux has some apparently redundant file-association settings, firefox seems to pick a "unusual" one, whose very reason to exist may be questionable.
Here's the solution, though:
Quote:
Originally Posted by the black cat
Re: Gimp default for opening PDF's from Firefox
I got a solution that works from another forum (see here). I have copied it below:
to make pdf open using a specific application when you double click it in the FF download manager, edit /usr/share/applications/mimeinfo.cache , search for: application/pdf= . Put the name of *application*.desktop of the desired application right after = .
So to use okular, it should look like this:
application/pdf=kde4-okularApplication_pdf.desktop
Notice the extra kde4- , this is necessary because okularApplication_pdf.desktop is in the subfolder kde4 in /usr/share/applications.
Replace okularApplication_pdf.desktop with whatever name of the .desktop file of the app you want. If it's in the same folder as mimeinfo.cache, i.e. /usr/share/applications then use the name of the .desktop folder, if it's in a subfolder then prefix it with kde4- , or kde- , whatever. See if this works.
mimeinfo.cache is a dynamic file and will be changed automatically when you install/uninstall a programme (this explains what happened when you uninstalled gimp). Of course you can keep a local copy of this file maintaining your own associations across reinstalls), you need to put this copy in ~/.local/share/applications , also a copy of /usr/share/applications/defaults.list
I got a solution that works from another forum (see here). I have copied it below:
to make pdf open using a specific application when you double click it in the FF download manager, edit /usr/share/applications/mimeinfo.cache , search for: application/pdf= . Put the name of *application*.desktop of the desired application right after = .
So to use okular, it should look like this:
application/pdf=kde4-okularApplication_pdf.desktop
Notice the extra kde4- , this is necessary because okularApplication_pdf.desktop is in the subfolder kde4 in /usr/share/applications.
Replace okularApplication_pdf.desktop with whatever name of the .desktop file of the app you want. If it's in the same folder as mimeinfo.cache, i.e. /usr/share/applications then use the name of the .desktop folder, if it's in a subfolder then prefix it with kde4- , or kde- , whatever. See if this works.
mimeinfo.cache is a dynamic file and will be changed automatically when you install/uninstall a programme (this explains what happened when you uninstalled gimp). Of course you can keep a local copy of this file maintaining your own associations across reinstalls), you need to put this copy in ~/.local/share/applications , also a copy of /usr/share/applications/defaults.list
I wonder how these people find out how to fix this sort of thing among all the mess that linux configuration files are.
As a sidenote, I didn't have to copy this "defaults.list" file, which does not even exist on my system (debian wheezy/sid, testing). Otherwise it works, and you don't even need to restart firefox.
Total Comments 7
Comments
-
Thanks for this post. Though I tried using it for PackageKit .catalog files, the web server actually identified the mime type as text/plain so no luck there.
Anyway, to make it permanent until the package for the program it self is updated, you can edit the desktop file it self for the correct programs.
Open up
gimp.desktop and remove "application/pdf" from it's MimeType list.
Equally so, make sure the same is added to the one you want to use.
The next program that installs a desktop file will then run the program to re-cache the info in the desktop files. I'm not sure how it decides on the order though. As mine goes "calibre-gui, evince, calibre-ebook-viewer" So alphabetical order is not a priority. In the same directory, there is also a default.list file that contains entries as well. Not sure what writes that file.... It' might be part of xdg-mime. On top of that, there is another file that gets edited by various things in ~/.local/share/applications/mimeapps.list
So... yeah... lots of modifications to consider. The best bet, I would hope, is to default it in the user's home directory... but if you are using xdg-mime, that's probably where it set it and firefox is reading the other settings in the applications directory.... Or gimp is listed first in file the user's home...Posted 08-20-2011 at 12:29 AM by lumak -
You're welcome.
I think that despite of the fact that it's not gimp's business to open PDFs and thus it shouldn't be in it's gimp.desktop, the other way around, changing the file-type configurations is a bit safer because, as someone else posted on those threads from which I've quoted this post, you may well just uninstall gimp (or change gimp.desktop) and then it will try to open the pdf with krita, because the pdf settings are stupid.Posted 08-30-2011 at 02:32 PM by the dsc -
I can't get firefox to have konqueror/kfmclient to be associated with "open folder", if pcmanfm is installed. That's quite annoying.
Posted 03-11-2015 at 03:09 PM by the dsc -
Annoying Firefox' associations issue II, the return
The file manager association seems to be because of a combination of a Dbus-method that is more or less Gnome-specific/not widely adopted elsewhere, and a myriad of possible locations of xdg-mime config files.
For the Dbus part one may need do rename/delete a file called "org.freedesktop.FileManager1.service" located at /usr/share/dbus-1/services/ and $HOME/.local/share/dbus-1/services.
It's a ".desktop" kind of thing, I originally thought I could edit it and put konqueror in the "exec" part, but it seems it's not compatible, or maybe that the whole xdg thing was what was really going on, even though it didn't look that way.
The deal with the xdg system is that there can be config files everywhere.
Here's a list, from ArchWiki:
Code:$HOME/.config/$desktop-mimeapps.list user overrides, desktop-specific $HOME/.config/mimeapps.list user overrides /etc/xdg/$desktop-mimeapps.list sysadmin and vendor overrides, desktop-specific /etc/xdg/mimeapps.list sysadmin and vendor overrides $HOME/.local/share/applications/$desktop-mimeapps.list for compatibility but now deprecated, desktop-specific $HOME/.local/share/applications/mimeapps.list for compatibility but now deprecated /usr/local/share/applications/$desktop-mimeapps.list and /usr/share/applications/$desktop-mimeapps.list distribution-provided defaults, desktop-specific /usr/local/share/applications/mimeapps.list and /usr/share/applications/mimeapps.list distribution-provided defaults
What I hadn't noticed was that I actually had the $HOME/.config/mimeapps.list, which funnily enough had only the pcmanfm settings. All the others are set on $HOME/.local/share/applications, and the file over there even has both the directory lines, set to KFM.
For whatever reason the file at .config takes precedence over the other, at the same time it's not apparent on whatever command that would tell me the settings (but again, I'm not 100% sure on that, if I did that it was months ago, before I gave up).
The end...
...or is it?Posted 05-03-2015 at 07:45 PM by the dsc
Updated 05-03-2015 at 07:48 PM by the dsc -
I've got no mimeapps.list on my machine. I can temporarily solve problem by editing /usr/share/applications/mimeinfo.cache.
Problem is that after a while (probably some update) it goes back to previous (e.g. using krita for pdfs )
From Arch http://https://wiki.archlinux.org/in...t_applications I gotQuote:When the program update-desktop-database is run (usually as root during the (un)installation of a package), it updates files called mimeinfo.cache
Thus, removing the file /usr/share/applications/kde4/krita_pdf.desktop
and then running update-desktop-database I conclude that my /usr/share/applications/mimeinfo.cache at least for the moment looks as it should .
Let's hope it stays that way!
/Joakim
PS. I'm on Gentoo and KDEPosted 12-29-2015 at 06:12 AM by joakim -
Ok, when updating Calligra the desktop link quite naturally comes back...
But otherwise the recipe seems to work as it should.
update-desktop-database clearly needs to handle priorities between the applications in some way.Posted 01-05-2016 at 09:55 PM by joakim -
Linux has to makeup somehow, for not having viruses. "Linux doesn't have virus - it doesn't need them".
Posted 01-10-2016 at 10:16 PM by the dsc