[SOLVED] Slackware 13: Firefox applications list sparsely populated
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Slackware 13: Firefox applications list sparsely populated
Hello
Where does Firefox 3.5.2 get its applications list from? I mean the ones in Firefox->Edit->Preferences->Applications. On my new install there are only 8 listed whereas the equivalent on ubuntu 8.04 has more than 40 ... ?
catkin, I noticed that too: Firefox in 13.0 seems to want to open EVERYTHING in Konqueror :/
But just haven't gotten around to adding more applications; I might just boot up my Slack 11 system and grab the application "launch codes" from that, as I had it configured pretty thoroughly.
I'm not sure how to use a GUI method to add applications (there may well be a way, but I've never looked for it) but you CAN add applications and configure them using the trusty about:config page.
If you're still looking for some help on this later on, I may go and load up Slack11 here shortly (or mount the partition and see if I can grab the 'launch codes' by that route, and post here what I come up with.
Thanks Sasha I was hoping to find the source of the Applications list entries in about:config. The ones that do exist are in the gecko.handlerService.schemes.* entries but that list is the same on both ubuntu and Slackware so the gecko entries are not the only source of list entries. There's a related thread on the Arch Linux Forum complete with a script to workaround the problem and suggestions that Firefox uses Gnomes MIME types but netsearching didn't turn up anything more.
Check out the above link. It looks like it's not as clear-cut as it used to be, and varies by mozilla product :|
That page describes a FF Extension called "MIME Edit Extension" but I didn't see it explicitly mentioned wrt FF 3.x+ but I am going to go and see if it exists for 3.5.3
Also, I did find on my Slack 11 installation, inside the .mozilla folder, a file called "mimeTypes.rdf" which appears to contain the external application configurations for various MIMEtypes and other files that the browser might encounter, and what to do with them.
According to that link again, it says that you *can* edit this file, but they advise against it because it's a little confusing and probably easy to bork up.
The simple way, although not my choice of ideal ways to do this, would be to encounter content, download/click it, and use the "What should I do with this File" dialog, to gradually configure different apps for different filetypes, but this is tedious IMO.
I'm going now to look for that MIME Edit extension. Chaek out that link, as it provides a load of related links too
Well, when you get back, you may wish to download and try out this UNOFFICIAL mime-editor, which is a compatibility re-work of one of the few existing MIMI Editor extensions.
I got the link by reading the comments/feedback on the mozilla addons page for the MIME Editor extension which is not compatible with FF 3.0+
I have just installed it and restarted FF, and all looks fine; the thing appears to be installed successfully -- no weird errors.
I'll try to add some external applications and report back.
There's an older discussion of this situation, which is worth reading..
FWIW, the modified MIME Type Editor I linked to above really isn't helping me. It basically just duplicates the functionality you get by using the "What to do with this file" dialog.
I've got it disabled at the moment, and will probably remove it later.
A bunch of stuff re: Firefox + external KDE apps & MIME-types
I'm not sure at this moment what DE the OP is using, but for the sake of this post, I'll assume you're using some combination of Xfce and/or KDE for the DE and the apps you use.
Previously (Slack 11) I used KDE, but currently I'm using Xfce but I still use Konqueror, Kwrite, and other KDE apps sometimes.
Here's a bunch of stuff I came up with, in not really any particular order, all of which has to do with how Firefox deals with MIME types and opening external applications.
Info: I can't clearly distinguish between the functions of the about:config entries, versus what's contained in the ~/.mozilla/firefox/<your-profile>/mimeTypes.rdf file, and how each or both of them influence how external content is handled. So, I'll just provide all possible information here, and everyone can do what they like with it
Before deciding to do anything at all, based on what I write here, please read the entire post. There appears to be (as usual) more than one way to skin this fox.
NOTE #1: To see or change the action that Firefox 3.5+ takes, when encountering content that it has ALREADY ENCOUNTERED once, you can use Edit -> Preferences -> Applications. The stuff you see in there, corresponds to the "mimeTypes.rdf" file, which will be discussed below. This stuff gets configured when you use the dialog box "Select application to open this with".
Section 1: Make FF use KDE apps to open stuff:
(there's surely a way to do a similar thing with Xfce apps, but I haven't looked into it; maybe someone else can add that section.)
Create yourself a script; I call mine kfmclientexecscript4FF and place it in /usr/bin.
Here's what goes in it:
Code:
#!/bin/bash
/usr/bin/kfmclient exec $1
exit 0
That script will be called by Firefox when it wants to use an external KDE application. One really handy thing that this does, is allows you to "Open Containing Folder" when you right-click an item in your Firefox downloads list. It also allows FF to call PDF applications, text editors, etc., when you want to open a downloaded item with an appropriate application.
In order for the above to work, you need to make a few entries in about:config as follows:
There. Now FF can open containing folder of downloaded items, and can (hopefully) make intelligent choices about what apps to use to open downloaded items.
NOTE: I tested this with some PDF files, a text file, and opening my downloads folder, and they all work fine, however (at least with Xfce) the freshly opened application does not come to focus above the browser, as I would like & expect it to, despite configuring the Xfce settings manager to "Give newly opened windows focus". Maybe it's because they're KDE applications I'm using instead of Xfce apps, I don't know, but if you find a work-around or solution for this, I'd like to know about it
Slackware does not seem to include a file called /etc/mimetypes which is referenced in the firefox about:config page. However, I was able to find a nice, fully stocked mime type file located at /usr/share/mime/types, and also a local file in my home folder called ~/.local/share/mime/types, but in order for Firefox to be aware of these files, you need to edit an about:config entry (here are FOUR entries, two for MIME-types, and two for mailcap files):
Doing a search on your machine will turn up several other samples/examples of mailcap configurations. Surely a Google search will also turn up loads of other stuff you can put in there. Basically this file lists MIME-Types, and the application you want associated with them.
As for the mime-type files, my local one is a lot shorter than the one in /usr/share/... but you should probably have similar ones on your system.
This file seems to be where firefox stores its own configuration of what to do with various MIME-types, like what application to use for them. Maybe if it dosn't have something in here for a particular MIME-type, it looks in the mailcap file(s), or vice versa. The way I see it, the more information you provide to the browser, the better it might be able to deal with external content.
Initially, on my Slack64-13 install, the file is 4.3Kib in size. However, I grabbed the one from my last Slack-11 Firefox, and found it to be 14.0 Kib. So, I copied the old one into the place of the new one. Here it is, if you want to use it (close your browser completely, backup your file, and replace mimeTypes.rdf with this file):
NOTE: In the above file, in places where you see NC:alwaysAsk="false" you can change that to "true" and it will cause Firefox to pop up a dialog box, asking what you want to do for that action. The dialog box will have a check-box for "Remember my setting for this" or some such thing, which will make the dialog pop-up NOT appear from that point on, if you check it.
Section 3: Miscellaneous:
Finally: I did a diff of my old Slack-11 FF's prefs.js file against the new FF 3.5.3 prefs.js file, and discovered a lot of differences. Of course this is to be expected generally, but I haven't taken the time to examine every change and see if anything in the old file has anything to do with external content, yet is missing from the new file.
Prefs.js is for the most part, where your about:config entries are stored.
You can edit the file, with the browser closed!! The browser re-writes the file when it closes, so close the browser first before editing the file.
If you want to delete entries from the file, you can just un-set them in about:config, and close the browser. They will then be gone.
Best of luck; if anyone has more to add, especially info about launching external Xfce or other DE applications from FF, or more entries to put in our mailcap files, please post away!
Thanks Sasha for doing so much research and sharing it so nicely
A little history may help understanding:
"MIME" stands for "Multipurpose Internet Mail Extensions". It was originally used by mail clients to determine which program to run to display a non-text mail component, (hence /etc/mailcap and ~/.mailcap as the configuration files).
It was adopted by Web browsers when, strictly speaking it is called "MIME Types" (hence /etc/mime.types and ~/.mime.types as the configuration files).
Now it is used by desktops, especially file managers, not only to choose the program but also to choose the icon (hence /usr/share/mime/, /usr/local/share/mime/ and ~/.local/share/mime/ as the configuration file directories, configurable by XDG_* envars).
Thus we find ourselves in the midst of emerging standards. The structure of the desktop configuration files-and-directories is a lot more complex than the mail and browser configuration files. Being as how Firefox is nice enough to be able to use the desktop configuration files, I would have liked to use them so the desktop and file manager would ues the same MIME configuration data as Firefox but I was not able to make it work.
I'm using Xfce so did not investigate the KDE specifics.
Regards ~/.mozilla/firefox/<your-profile>/mimeTypes.rdf, it does seem to be where Firefox stores its own configuration after taking data from the "helpers.[(private)|(global)]_[(mailcap)|(mime_types)]_file"s as shown in about:config and after interacting with the user.
Thus the easiest way to get Firefox's Applications list set up would be to copy mimeTypes.rdf from a previously set up installation. Curiosity and a desire not to carry old baggage forward stopped me from doing so.
On as-installed Slackware 13, /usr/share/mime/types lists many applications but does not associate any programs with them. It does not include application/x-bittorrent.
I set helpers.private_mime_types_file to ~/.local/share/mime/types and created the referenced file containing
Even after restarting Firefox it neither had an extra entry in Edit->Preferences->Applications nor knew about /opt/vuze/vuze when I opened a torrent file.
Netsearching, including the feedesktop.org site, did not find many pages about using ~/.local/share/mime/types so I fell back to ~/.mailcap, creating it with this content:
Code:
###############################################################################
#
# MIME types and programs that process those types
#
# Users can add their own rules if they wish by creating a ".mailcap"
# file in their home directory. Entries included there will take
# precedence over /etc/mailcap
#
# The man page for update-mime(8) describes the fields
#
###############################################################################
application/x-bittorrent; /opt/vuze/vuze '%s'; description="BitTorrent client"; test=test -n "$DISPLAY"
Now, without restarting Firefox, Edit->Preferences->Applications was stiil the same but opening a torrent file resulted in being asked whether I wanted to open it using /opt/vuze/vuze.
It would be nice to get Firefox using the desktop MIME files -- and nice to understand how the many desktop MIME files work -- but the existing setup is "good enough" and other tasks have a higher priority.
Thus the easiest way to get Firefox's Applications list set up would be to copy mimeTypes.rdf from a previously set up installation. Curiosity and a desire not to carry old baggage forward stopped me from doing so.
Yes, that's exactly what I DID do and am happy with the results in the browser.
The application-associations from the previously set-up firefox, appeared in "Edit -> Preferences -> Applications", and are editable/configurable via that GUI, and if you wish to REMOVE anything from there, the easiest way (though not necessarily *simple*) is by removing it from mimeTypes.rdf.
Before deciding to do anything at all, based on what I write here, please read the entire post. There appears to be (as usual) more than one way to skin this fox.
hm... I like pundits
Quote:
Originally Posted by GrapefruiTgirl
Slackware does not seem to include a file called /etc/mimetypes which is referenced in the firefox about:config page. However, I was able to find a nice, fully stocked mime type file located at /usr/share/mime/types, and also a local file in my home folder called ~/.local/share/mime/types, but in order for Firefox to be aware of these files, you need to edit an about:config entry (here are FOUR entries, two for MIME-types, and two for mailcap files):
Doing a search on your machine will turn up several other samples/examples of mailcap configurations.
I didn't have an /etc/mailcap file, so I created one. I couldn't find 'bittorrent-xterm' so I when I cut and pasted from your example I commented that out (Don't wanna try to d/l a torrent and have firefox compain it can't find the app).
Also, as I'm sure you already know, my javaws (The whole reason I found your post) is located in lib, as oppsed to lib64. I'll build a multi-lib Slack64 later and play with that
I've cut and pasted the xml above into mimeTypes.rdf-replacements since I dont' want to 'lose' any functionality, and I also want to make sure that I have the apps that are listed in yours. I'll go through this later.
Basically, the whole reason I ended up here is because when I tried to register NetBeans, there wasn't any way to handle a jnlp
I don't know if I had this handling prior to upgrading to FF 3.6, but I really found your post enlightening
Okay Sasha, but... what is your reasoning in doing it this way as opposed to doing an ln -s /usr/share/mime/types /etc/mimetypes ??
Wouldn't that produce the same result? And if so, then what are your thoughts on the different methodologies for achieving this goal?
At a glance, yes, linking the files as you suggest, will produce basically the same result; but there are at least two reasons why I would choose not to do that:
1) Since the browser has a separate config option for EACH of the two files/locations, then why not make use of them both? Remember, while the files may *look* the same to you and me, different applications may interpret each of the files differently, and/or use them for different purposes. Linking them to each other is IMO not a great plan.
2) files located either in /etc or in /usr/share have the potential to change and/or disappear at some time, during something like package updates, system upgrade, etc. so it is generally not a great idea to link such files to one another and "forget about it".. If the link target gets changed or removed, the symlink will be broken, AND now neither file will exist or contain any content.
3) instead of (2) above, it's best, where possible, to use a file in your $HOME folder, since files in there should be immune from system upgrades and that sort of thing. Stuff in your $HOME should be able to be depended upon to remain intact and unaltered, unless YOU specifically alter them.
In a case where there can be a version of a file in your $HOME as well as a version elsewhere on the machine, two things are often true: A) the one in your $HOME takes precedence, and B) there is often a way to "include" the system file, with some form of an "include" directive, which makes it so that your $HOME file gets read first, and *IF* a similar file exists on the system, it will get read and appended (or prepended, depending on where your #include directive is placed..) to the $HOME file.
Regarding #3-- I'm not aware of any #include mechanism for these mime/rdf/mailcap files in this context of Firefox, so, referring back to what I wrote for #1 I think it's best to make use of the browsers provision for EACH of the files, rather than symlinking files together and pointing the browser at only one location.
Sasha
Last edited by GrapefruiTgirl; 02-26-2010 at 11:52 AM.
Thanks Sasha for doing so much research and sharing it so nicely
I have to second that
You've really provided a clear, concise, step by step procedure for both affecting these changes, as well as the reasoning behind it that provides one with the background as to why they may want to make some or all of these changes.
wrt my question regarding the linking of /etc/mailcap, I kind of expected your response to be what it was, although having it confirmed was a relief.
Things have changed over the past few years wrt the ways in which we treat our customizations, and the installation of apps in Slackware. We used to do a lot of installing by hand but nowadays we (the Slackware user community) are best served by building our own packages, preferably with SBo's, for the sake of upgradability and longevity in the context of managing the system as time passes.
Okay then! Dugan had a couple of things mentioned that weren't covered here, although they mostly affect the handling of file types where proprietary software is concerned, instead of what's already available for handling such files (Like .pdf's, etc...)
I haven't followed his guide for mplayer or Realplayer (by installing or recompiling them) so obviously, I haven't affected those changes in about:config yet.
Actually, I haven't checked out the mms or rtsp entries yet so I fully understand what they do either, so I haven't added them yet either
If anyone wants to address the significance of those entries I'm all ears.
um... non sequitur here: I'm configuring Chrome with the extensions that I want to have available, and just wanted to mention that 'one' of the reasons that Slackware 'might' be the distro of choice for folks out there over some of the others, is that in Slack, when you d/l and install google-chrome from SlackBuilds.org, you've actually installed "Chrome", and not "Chromium" - which is a good thing IMO.
The differences are indeed subtle, yet I wanted "Chrome". One of those reasons is that, according to Google, "Chrome" can update, where "Chromium" can't. We'll see
Finally (and back to the matter at hand), what brought me to this thread initially was the inability of Firefox to run Java Web Start. That's been implemented now thanks to you
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.