There are currently a number of things which are "broken" wrt how Nautilus deals with thumbnails. One of the symptoms is related to how Nautilus deals with symlinks. Basically, thumbnails are regenerated unnecessarily in a number of cases. The first case is, say, I have a directory $HOME/Movies/futurama and it contains a lot of (legal) Futurama episodes. I also have a symlink to $HOME/Desktop/Movies. I'm managing my files and access "Movies" from "shahms's Home" and, after a significant amount of time, I have thumbnails for all of the videos. I then decide I want to watch one of the videos and open "Movies" from the desktop. Surprise, surprise, every single thumbnail is regenerated. Of course, this is just a symptom of the fact that Nautilus' symlink handling is a little . . . counterintuitive. In attempting to make access to some commonly viewed directories, I have links to them on my desktop. In a rather stark violation of the spatial metaphor, nautilus will happily open two views of this single directory (and, more irritatingly, generate thumbnails for all of the files in both of them) depending on how I access it. I (kind of) understand the motivation behind making "Up" refer to the parent directory of the symlink, but as far as the "uniqueness" of a folder goes (both for views and thumbnails) shouldn't the dereferenced name be used? Skipping back to thumbnails... Say I decided to rename Movies/futurama to Movies/Futurama. Wham. There I am again, regenerating all of the bloody thumbnails again. Sure I can manually canonicalize the new urls and rename the thumbnail files appropriately, but shouldn't Nautilus take care of this for me? I can understand if I rename a folder or a file from the command line, but it seems like nautilus should be tracking this stuff for me. Renaming a single file, however, does "remember" the thumbnail. This would be much less of an issue if generating thumbnails didn't take for-freakin'-ever. It's especially irritating in light of the fact that both gst-thumbnail and totem-video-thumbnailer often successfully thumbnail files that the other will not or for which the other generates "broken" thumbnails. In my specific case, it means I went through, generated thumbnails initially changed thumbnailers and "touched" the appropriate files to regenerate the thumbnails. Don't really want to have to do this twice because of the symlinks. And I don't want to do this every time I decide to reorganize things and rename directories. From reading the thumbnail spec, it appears as though at least some of this is "desired" behavior. Yes, md5summing the canonical URI to a file means thumbnailing can work for any type of resource and speeds up thumbnail generation for the common case. But it also breaks horribly in a number of other cases and seeing as you're going to have to download the remote file to thumbnail it anyway, shouldn't the md5 of the actual file be used instead? Or at least as a backup: if not path_md5_thumbnail: if content_md5_thumbnail: copy(content_md5_thumbnail, path_md5_thumbnail) else: thumbnail = generate_thumbnail() copy(thumbnail, content_md5_thumbnail) copy(thumbnail, path_md5_thumbnail) That small change would even work without modifying the symlink behavior (which should probably still be fixed anyway), but would require changing the thumbnail spec. I suppose I should propose the change on xdg-list, but I thought the suggestion might be appropriate here as well. -- Shahms E. King <shahms shahms com>
Attachment:
signature.asc
Description: This is a digitally signed message part