Re: symlinks, thumbnails and minor irritations

On Mon, 2004-05-24 at 00:01, Shahms E. King wrote:
> 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?

This has been hotly debated before. See the list archives. The decision
last time was to not follow symlinks, but introduce "shortcuts" into the
ui that are resolved upon activation.

> 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.

Yes. This is a problem with the way the spec works. We could do better
in some cases, if the change is made through nautilus. If someone could
work on that that would be nice.

> 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:

Eh? md5suming a file means reading all of it. Thats basically as slow as
thumbnailing a whole image, and typically *much* slower than
thumbnailing a video (that only reads some initial frames).

 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's an unconventional Republican sorceror who hangs with the wrong crowd. 
She's a radical Bolivian safe cracker in the wrong place at the wrong time. 
They fight crime! 

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