|
Firefox/Iceweasel workaround: "Open containing folder" with user defined filemanager
Although many proposals can be found to be able to open download folders with a file manager of user's choice (e.g. via "xdg-open file:///path/to/the/dir/" ), nautilus still seems hard coded in the linux versions of Firefox (a.k.a. "Iceweasel" in Debian).
You may find dozens of clues, how someone at some time managed to achieve that ... ranging from gconf-editor over mimeTypes.rdf and/or defaults.list (each of them on system or per user level), mimeinfo.cache to about:config. But at present (Firefox 6.0.2) none of them works, apart from the most brutal workaround, which replaces /usr/bin/nautilus by a link to /usr/bin/konqueror. But at least in a multi-user environments that is inflexible, too, and above all will only work until the next update. Therefore, as long as Mozilla won't change anything, it seems preferable to prepend $PATH with some user defined folder. For example. in ~/.bashrc define: Code:
PATH=~/bin:$PATHCode:
chmod u+x ~/bin/nautilusThen we just have to extract the "containing folder", which shows up by the user defined "%c" and replace any enquoted blanks and special characters, as most file managers won't deal with them. Fortunately again, bash can to that for us even without external tools (like sed). Finally, nothing detains us from opening the download folder with a file manager of our own choice; as a user of KDE this is likely to be dolphin, konqueror or krusader. Konqueror can even be forced into a certain layout using the "--profile" option (called "downloads" in the example below). At last, now for the example, ~/bin/nautilus: Code:
#!/bin/bash |
why go to all this trouble when you can just use edit > preferences > applications to select your preferred file manager?
|
For those two major reasons:
* I would expect these to work in the browsers web context , but not in the "open containing folder" dialog, which is somewhat separate (other words: browsing the web, not the local filesystem). If it was not, I would expect the usual "open with <select...>"-Option, which is missing, too. * There is no entry for "folder", "directory", "inode", "file" (or the respective localized phrases). However, if a file browser could be configured, and nautilus was just a default, I would expect an entry for nautilus. Which isn't there. Anyhow, have you managed to do so? |
If you're talking about when you right-click a download and it says Open Folder, you just go to that menu and pick your file manager next to the File entry (choosing Use Other if necessary to find the executable for your file manager).
I might be misunderstanding what you're trying to do with this though, or maybe its fixing an issue that isn't present in Slackware (guessing that you use debian). |
3 Attachment(s)
> ... and it says Open Folder, you just go to that menu and pick your file manager next to the File entry ...
You are right: There is *no* such "Other"option available or "Open with...", just "Öffnen" ("Open", which starts an application associated with a certain file type), "Beinhaltenden Ordner anzeigen" ("Open containing folder", which obviously is a hard coded call to nautilus on Linux versions of Firefox) and four further, but not relevant context menu items. For further clarification, I'll attach screenshots from Debian, openSuSE and Ubuntu 11-4. (The only way you use do is: open a containing folder in nautilus, go to its parent folder, "open" this by "with..." (using nautilus' own context menu) with e.g. konqueror, close nautilus and re-enter the subfolder you came from in konqueror. But that's a quite toilsome procedure, isn't it?) |
Quote:
Because I've also discovered after going Quote:
Quote:
Quote:
Quote:
Quote:
|
Sigh, I'd be glad if it was such easy. After upgrading to Firefox (a.k.a. Iceweasel in Debian) to v. 30 I realized that the trick mentioned above (using a customized ~/bin/nautilus) doesn't work anymore. At first sight one could believe that's just because Firefox on Linux/KDE now does not start "nautilus" anymore, but another file browser called "caja".
But to my surprise, using a customized ~/bin/caja (with ~/bin prepended to $PATH) does not help anymore, too. (I tried to find out what is going on under the hood using "strace -f iceweasel", but have not found anything usable). The only constant thing in this misery: the most obvious thing (going "edit > preferences > applications" and setting [Content Type]:file as desired) has had no effect years ago and still does not today :-( |
Create the file /usr/share/applications/mimeapps.list with the following content:
Code:
[Added Associations]For some reason firefox and thunderbird ignore the current user's setting regarding mime type handler priority, so the priority has to be configured system wide. Works also for PDF (never again gimp-autostart if I just want to read a pdf) |
Dear cepheus11,
thanks for your suggestion! I've created /usr/share/applications/mimeapps.list with the proposed content - to no avail. After restart Firefox still starts an application that introduces itself as "caja" when I ask to "open containing folder". But now for something even [/B]very[B] more strange: # ll $(which caja) 5244947 0 lrwxrwxrwx 1 root root 18 Jun 30 15:49 /usr/bin/caja -> /usr/bin/konqueror Well, that's because yesterday I replaced /usr/bin/caja with a link to konqueror (just following the old wisdom, by which, if the mountain won't come to the prophet, the prophet must go to the mountain). But, even that did not work. So the only reasonable concusion to me seems that this mysterious "caja" is built-in into iceweasel...!? To further prove that, I just purged 'caja' ans 'caja-common' (including dependencies: mate-core, mate-desktop-environment, mate-desktop-environment-core, mate-desktop-environment-extras). Closed Firefox. Restarted Firefox. Then, once more: Open containing folder. Help/about: Caja 1.8.1! What the hell is going on there? Just for completeness: * Iceweasel (a.k.a. Firefart) version 30.0 * debian/testing (64bit), up-to-date * KDE desktop (version 4.13.1) |
Hm, this is strange. Try with a clean firefox profile:
Code:
mkdir /tmp/ffclean && iceweasel --no-remote -Profile /tmp/ffcleanYou could also strace firefox: Code:
strace -f -o /tmp/fftrace iceweaselQuote:
|
No need to worry, I'm a passionate KDE user and therefore not affected by deinstallation of some MATE packages. For the same reason, there were surely no other running processes of caja, and to be sure about that I had issued "killall caja" before each test.
Here is some further information collected today:
According to that, FF seems to send a message to somewhere (maybe on one of six running instances of "dbus-daemon", three of them running as root) via somewhat (Session Bus?) asking for "org.freedesktop.FileManager1". Whatever process is fulfilling this request does not know about the user's environment (at least not user's $PATH), because "/usr/bin/nautilus" gets precedence over /home/$USER/bin/nautilus (/home/$USER/bin/ is first part of user's $PATH). Just for testing purposes: if we replace /usr/bin/nautilus by a link to the script "/home/$USER/bin/nautilus", it works again like it did the past some years. However, messing up /usr/bin/ is not my intention... So the residual question is: where to configure konqueror instead of nautilus for "org.freedesktop.FileManager1"? |
Hm, this is freedesktop's specification of the filemanager dbus interface: http://www.freedesktop.org/wiki/Spec...ger-interface/
But I don't get what they are talking about. What does happen when you do in a console window in the KDE session: Code:
xdg-open /homeIs konqueror selected as primary file manager in KDE systemsettings? And please post the output of Code:
qdbus |
That soothes me - I don't get what they are talking about, too :)
Having the softlink from /usr/bin/nautilus to my script active, I added one line into it: Code:
PARENTNAME=$(ps -eo "%p %c" | grep $PPID | cut -f2 --delimiter=" ")PARENTNAME=dbus-daemon, PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games, USER=meiner This confirms that dbus-daemon is acting on behalf of firefox, and dbus-daemon has an environment with a $PATH different from $USER and root. Then, after setting everything back to normal (that is, original /usr/bin/nautilus restored), the answers to your questions are:
I'm curious what tha last one can tell you. Would you think it's a good idea to move /home/$USER/bin/nautilus (the switching script) to /usr/local/bin/ ? Or, if things are done by a dbus-daemon instance running as $USER, make dbus-daemon's environment have $USER's path (which should restore the behavior that me and some other people lived very happy with)? At the moment, this seems most after my fancy. |
Quote:
My theory is that there are dbus interfaces running in your session, which I don't have. And that iceweasel preferes some gnome-related interface for opening directories. My qdbus output is much shorter than yours. Try to find out what starts all these dbus interfaces, and if there is a possibility to prevent that. Quote:
|
I use KDE 4 in Debian Jessie, and everytime I clicked "Open Containing Folder" on a downloaded file, Iceweasel weirdly lauched qmmp (the music player). Being a dummy linux user, what I did was go to KDE systemsettings (Start Menu > Settings > System Settings) and in "Default Applications" I changed from Dolphin to Konqueror. Then Iceweasel started using konqueror to open folders. Then I changed it back to Dolphin, and now it uses Dolphin.
|
| All times are GMT -5. The time now is 06:20 AM. |