Benedikt Meurer JavaScript Engine Hacker and Programming Language Enthusiast.


It took quite some time and it wasn’t very enjoyable, but now Thunar finally supports thumbnails (at least loading):

It’s not yet committed tho. Fortunately most desktop applications already store thumbnails today, so the file manager seldomly needs to generate a thumbnail itself. For the generation, we’ll support whatever GdkPixbuf supports (we’ll probably also include a fast jpeglib based generator), and optionally support the GNOME thumbnail generators. The GNOME thumbnails generators are just tools that write the final thumbnail to a file specified on the command line, which is good. Unfortunately the GNOME guys decided to store the generator list in GConf, which means that the GNOME thumbnailer support will depend on GConf, and thereby comes at a certain price.

The thumbnail loading is quite fast, but nevertheless adds a little overhead (both memory and CPU time). Therefore we’ll most probably include an option to disable thumbnailing completely. The good news is that Thunar is still very light on memory. A quick and dirty measurement (on a FreeBSD/i386 5.4-STABLE box with Gtk+ 2.6) shows, that Thunar’s VmData size is at 2228 kb after startup (displaying the first 12 items from my home dir). For example, Nautilus’ VmData size is 4368 kB after startup displaying the same set of files (in browser mode and without the sidebar), while ROX is at 2988 kB and Xffm-iconview is at 2532 kB. Of course this is far from a serious benchmark, but it tells me that we’re on the right way.

What we really need with Thunar (or in a separate tool based on Thunar-VFS) is a way to cleanup dead thumbnails:

$ ls -1 ~/.thumbnails/normal|wc -l


For the sake of completeness: Konqueror’s VmData size is 4364 kB (KDE 3.4).