There are several caveats in what you tried to do. I already mentioned the danger introduced by your approach:
Next time nautilus is going to be updated, your dolphin gets overwritten (as your link points there). Same goes for gnome-terminal.
So we figured, this was not a good idea :)
But there are some ways to try working around, so "x" gets run when "z" was requested -- but I'm not aware of any as soon not "z", but "/full/path/to/z" gets called. As long as it is just "z":
- creating an alias for z, like
alias z=x
(works on a per-user-level -- or globally, depending on where it was defined)
- creating a "replacement" for z in a location mentioned in the PATH before the location the real z resides in
A little more details on the second approach. Taking your original problem, you want to have dolphin executed whenever nautilus is called upon. You already found nautilus at /usr/bin/nautilus
. Now let's (probably correctly) assume your $PATH
contains (in this order) /usr/local/bin:/usr/bin
-- so you see /usr/local/bin
would be searched before /usr/bin
. So we simply create a shell script /usr/local/bin/nautilus
with the following content:
#!/bin/bash
/usr/bin/dolphin %$@
So what will happen? If you (or some script/program/daemon/...) invokes nautilus
, this will execute /usr/local/bin/nautilus
(as this is the first "nautilus" found in the PATH), which simply starts /usr/bin/dolphin
-- voila! But if the "whatever" uses the full path, this won't work.
So you say: Hey, why didn't Izzy say "just do a ln -s /usr/bin/dolphin /usr/local/bin/nautilus
?" Sure you can do that -- and it will work the same. But using a script as shown may come in handy if you need to introduce additional parameters which are not passed with the original call. With above script, dolphin simply gets passed the same parameters the original call used (%$@
). But you can play around with things in the script, replace parameters, etc. As for your current problem, the link would be enough (as long as nautilus doesn't get called with the full path).
Nautilus's thumbnailing routines actually come from the libgnome-desktop
library, so it is possible to run the same thumbnailers outside of the file manager.
The API is a little complex, but the following Python script should help:
#!/usr/bin/python
import os
import sys
from gi.repository import Gio, GnomeDesktop
def make_thumbnail(factory, filename):
mtime = os.path.getmtime(filename)
# Use Gio to determine the URI and mime type
f = Gio.file_new_for_path(filename)
uri = f.get_uri()
info = f.query_info(
'standard::content-type', Gio.FileQueryInfoFlags.NONE, None)
mime_type = info.get_content_type()
if factory.lookup(uri, mtime) is not None:
print "FRESH %s" % uri
return False
if not factory.can_thumbnail(uri, mime_type, mtime):
print "UNSUPPORTED %s" % uri
return False
thumbnail = factory.generate_thumbnail(uri, mime_type)
if thumbnail is None:
print "ERROR %s" % uri
return False
print "OK %s" % uri
factory.save_thumbnail(thumbnail, uri, mtime)
return True
def thumbnail_folder(factory, folder):
for dirpath, dirnames, filenames in os.walk(folder):
for filename in filenames:
make_thumbnail(factory, os.path.join(dirpath, filename))
def main(argv):
factory = GnomeDesktop.DesktopThumbnailFactory()
for filename in argv[1:]:
if os.path.isdir(filename):
thumbnail_folder(factory, filename)
else:
make_thumbnail(factory, filename)
if __name__ == '__main__':
sys.exit(main(sys.argv))
Save this to a file and mark it executable. You may also need to install the gir1.2-gnomedesktop-3.0
package if it is not already installed.
After that, simply invoke the script with the files or folders you want to thumbnail as arguments. Thumbnails will be saved to ~/.thumbnails
where applications like Nautilus expect to find them.
Best Answer
Introduction
So it turns out that KDE and GNOME now follow slightly different thumbnail naming and metadata conventions. This is quite unfortunate since issues like these were supposed to be eliminated with the work of the Free Standards Group.
I've filed a bug report with KDE that will hopefully get this addressed eventually, but for now thumbnails generated by KDE and GNOME are sadly incompatible with each other.
Thumbnailer script to bridge the KDE/GNOME gap
In order to work around this incompatibility, I ended up modifying the Python script that James Henstridge posted in the Q&A linked to above. The main change I implemented is a function that updates the generated thumbnails to be recognized by KDE (by renaming them and updating the PNG metadata chunk).
Here is the aforementioned script in its current revision:
Installation
Copy and paste the code section above into a new file, choose a fitting name for it (e.g.
thumbnailer
), and mark it executable.Dependencies
For the script to work properly you will need to have the python bindings for GNOME installed. The script also depends on Python's
pillow
library which may be installed viapip
.The following commands should take care of all dependencies:
Thumbnails are first generated through GNOME's thumbnail factory and then made compatible with KDE. So you will still need to have all the corresponding GNOME thumbnailer modules installed. KDE's own thumbnailers are not supported. E.g.: for the script to support generating PDF thumbnails you would have to install
evince
.(I would have loved to use KDE's python bindings directly, but it looks like both pykde4 and pykde5 have been abandoned for years).
Usage
The general use is the same as with any other thumbnailing script. Just invoke it with the files or folders where you want to generate thumbnails as arguments, e.g.:
References
Thumbnail specifications in KDE/GNOME:
Setting PNG metadata: