Re: [Nautilus-list] Thumbnail managing draft

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

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