[Nautilus-list] Re: Thumbnail sharing

[Darin Adler <darin bentspoon com>]

On Thursday, June 14, 2001, at 12:02  PM, Jens Finke wrote:

> 1. The global thumbnail directory is ~/.nautils/thumbnails, which is
> obviously bad. I would suggest to use ~/.gnome/thumbnails instead. The per
> directory .thumbnails can be reused anyway.

That sounds fine to me.

> 2. The other thing is, that most of the generated thumbnails contain the
> Nautilus specific frame around them. This looks quite nice within Nautilus
> but it makes them unuseable for other programs. Maybe these add-ons could
> be generated on the fly and not stored to disk. [BTW: Since I've read the
> sourcecode I finally understand that the frame depends on the image size.
> What's the idea behind this?].

I already asked Andy to change the Nautilus code to no longer include the 
frames in the thumbnails on disk. I think he's planning to do this soon as 
part of his work on making zoomed-in thumbnails look better (see item 1 
below). Storing them on disk was just a design mistake.

Beyond these issues, there are a few others that must be resolved to share 
thumbnails. The biggest ones I can think of are:

	1) Size. What size should a thumbnail be? Nautilus currently has a 
complex arbitrary rule for when a thumbnail is a certain size. For a 
future version of Nautilus, we want to create more than one thumbnail so 
you can generate a larger one for when people view the directory at a 
larger size. Various programs might need thumbnails of different sizes 
depending on what the rest of their UI is like. Andy was planning to work 
on this.
	2) Errors. What should be put in the thumbnail directory when a 
thumbnail can't be computed? Nautilus currently has a way to create an 
error file to indicate that the thumbnail couldn't be created to avoid 
trying over and over again each time you visit the directory. It also has 
a way to indicate "thumbnail generation in progress", and we'd ideally 
want to have that work even if the other program was making the thumbnail.
	3) File dates. Nautilus makes the thumbnails have dates that match the 
files they were generated from rather than the time they were generated. 
That way, the code can compare the date on the file with the date on the 
thumbnail for a (usually correct) check to see if the thumbnail needs to 
be regenerated due to changes in the file.
	4) Locking for thumbnail generation. If multiple programs are trying 
to create thumbnails at once, we have to make sure they don't overwrite 
each other or get in each other's way. This could be simple to solve, but 
I think there could be problems if we don't do anything about it.

> What do the Nautilus people think about thumbnail shareing? Is such a
> coorporation desired?

Sharing the thumbnails would be great. But I want to get it right and not 
break some of the subtle points in the thumbnail implementation.

    -- Darin