symlinks, thumbnails and minor irritations

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)
		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
Shahms E. King <shahms shahms com>

Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]