Re: [Nautilus-list] Thumbnail managing draft

[Jens Finke <jens triq net>]

Hello,

first, thanks for all the good suggestions.

On Tue, 10 Jul 2001, Darin Adler wrote:

> On Tuesday, July 10, 2001, at 08:09  AM, Jens Finke wrote:
>
> > Well, it's been some time ago now but I have finally written a first draft
> > about thumbnail managing.  You can find it also online at
> > http://triq.net/~pearl/thumbnail-spec/
>
> I personally don't understand the need for two qualities for thumbnails.
> If we must have two qualities, can't we have high quality as the default,
> and just use a .lq suffix for the low-quality ones?

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.

> [...] You don't mention if the .failed file should include the ".hq"
> or the ".lq" suffix or not. What if there's already a ".lq" thumbnail
> and you fail to create a ".hq" one? Should you create a ".failed" file
> or not?

In which cases can you create a lq but no hq thumbnail? As far as I
understand, hq tumbs need just more calculation time due to a more complex
algorithm (antialising).

But with the above mentioned systemwide setting the application would
always get the quality the user specified.

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

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

> [...]
> The Thumbnail size section should mention that thumbnails of different
> sizes go into different directories. Why do sizes use separate directories,
>   but qualities, use a file naming scheme? I think qualities should use
> directories as well.

I admit, this would be more consistent.

> When files are deleted, how do thumbnail files and directories (especially
> the ones in ~/.thumbnails in various users' home directories) get deleted?

I think this is a general problem. AFAIK there is no possibility to delete
unused thumbnails transparently. Maybe we should provide a function which
scans the users .thumbnail directory for unneccessary thumbs. But this
must be invoked by the user I think (eg.  an option in the
control-center).

> [...]
> This document does not describe the rules for how programs manipulate
> these directories that prevent them from getting in each other's way. What
> prevents a program from reading a partially made thumbnail that another
> program is in the middle of making right at that moment? That is not just
> a theoretical problem. And closely related to this is the use of the
> ".failed" files. What are the rules about respecting and managing them?

I try to find a solution in the next draft version.

Thanks again for your comment.


Regards,

    Jens