Re: [Nautilus-list] Thumbnail managing draft

[Darin Adler <darin bentspoon com>]

On Thursday, July 12, 2001, at 12:23  AM, Jens Finke wrote:

> Well, I just looked how nautilus handles thumbnails and it uses different
> qualities. This could be usefull on low end machines where antialised
> thumbnails need a lot more time for rendering. Maybe there should be a
> systemwide setting which thumbnail quality to use. So the user gets lq
> images for all applications.

OK, you misunderstood what Nautilus was doing.

The reason Nautilus has separate thumbnails for the anti-aliased and 
non-anti-aliased case is not speed. The *only* difference between the two 
is the frame that is used around the thumbnail, which we agreed should not 
be in the thumbnail files on disk. If we hadn't made that mistake of 
putting them on disk, we wouldn't even have anti-aliased vs. 
non-anti-aliased thumbnails in Nautilus.

If you read the code in Nautilus, you'll see that there's no low-quality 
and high-quality thumbnailing algorithm. You invented the concept on your 
own and you didn't even realize it!

> > It's not good to have each program generating thumbnails separately
> > deciding that the image is too big and creating ".failed" files based on
> > different rules. I think this feature needs some more thought. Also, an
> > image format that is unknown to one program might be known to another. 
> > How
> > will the ".failed" files handle that.
>
> The 'image is too big' thing could also handled by a systemwide setting.
> But the problem still exists if one uses different desktops which
> don't share these settings :-(.

Image is too big is not the only reason for failure. Other reasons could 
include a malformed image file, or a bug in the image library in the 
program that's trying to make the thumbnail.

> > More importantly, in what circumstances should a program take a ".failed"
> > file as reason to not even try to re-thumbnail, and under what
> > circumstances should the program try again?
>
> Yes, I noticed the problem too. Have to think about it more deeply. It
> seems to me that the whole idea of the '.failed' files is totally broken.
> [/me thinks about it to drop it completely].

Well you might want to drop it completely, but then you'd have to come up 
with an alternate solution to the problem. When we first implemented 
thumbnailing in Nautilus, we didn't have a mechanism like the ".failed" 
file, and we ran into problems where we'd retry to generate a thumbnail 
every time we visited a directory when there was something wrong with the 
image that we tried to thumbnail.

It's easy to say "lets just drop it", but we didn't add it on a whim. It 
was needed to solve a real-world problem.

One other question for your next draft. What should the user/group be on 
the thumbnail file? You say in the draft that the permissions should be 
the same as the original file, but that's not necessarily possible if, say,
 the original file was owned by root, and I had read but not write 
permissions to it. So I think you have to go into more detail for that.

    -- Darin