RE: [Nautilus-list] Thumbnail managing draft

["Ryan Muldoon" <rpmuldoon students wisc edu>]

Although Darin did a very good job of offering some suggestions, I'd like to
add a few thoughts of my own.

I agree with Darin's sentiment - why have two versions of the thumbnail?  It
seems like the relative rendering cost of a larger file isn't worth the
added complexity.  Not only does this complicate the file structure, and
increase space taken up on the hard drive, but now we have to quantify what
"low quality" and "high quality" are.  It seems like a lot of work without
much real benefit.  And, as this should ideally be adopted by as many
projects as possible, the simpler the standard, the more likely people will
use it. ;-)

Also, the .failed files also seem to introduce more problems than they
solve.  With a .failed file, you have to worry about locking, and, as Darin
astutely pointed out, when one program fails, it doesn't mean that another
will.  Nautilus may choke on a file that the Gimp can handle just fine.

I like the idea of setting the mtime and file permissions to be the same as
the original image.  I would probably just have equality checking do
	if (thumb.mtime != orig.mtime)
		generate_thumbnail(orig);
rather than
	if (thumb.mtime < orig.mtime)
		generate_thumbnail(orig);
because all you really care about is that they are in sync with each other.
So if they aren't, fix it.

I very much like the idea of multiple thumbnail sizes, as I think that icons
in general should be available in a variety of sizes, to avoid ugly scaling.
But I'd make the largest size 196x196 rather than 160x160.  That seems to be
what icon people are doing already.

Other than that, I think it is a great first cut.

	--Ryan

> -----Original Message-----
> From: nautilus-list-admin lists eazel com
> [mailto:nautilus-list-admin lists eazel com]On Behalf Of Darin Adler
> Sent: Tuesday, July 10, 2001 10:45 AM
> To: Jens Finke
> Cc: nautilus-list lists eazel com; eog-list gnome org
> Subject: Re: [Nautilus-list] Thumbnail managing draft
>
>
> 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?
>
> Instead of "The good thing about this is that it also detects thumbnails
> which didn't set their mtime to the original mtime and regenerates them."
> you should say, "If a program that generates thumbnails doesn't set the
> mtime to the original, it's not a fatal problem. Another program that
> implements the rule properly will simply regenerate the thumbnail."
>
> In the places where you say "informations" it should just be "information"
> . Instead of "random text strings" you should say "arbitrary text strings"
> . Instead of "store also" it should be "also store".
>
> There should be a URL for the PNG standard in the document.
>
> Perhaps the keys should be "OriginalHeight" and "OriginalWidth" and
> "OriginalSize" to avoid confusion.
>
> 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?
>
> 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.
>
> 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?
>
> Typo: "programm", "programms".
>
> 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.
>
> When files are deleted, how do thumbnail files and directories
> (especially
> the ones in ~/.thumbnails in various users' home directories) get deleted?
>
> You need to define what an "escaped URI" is. Nautilus uses a particular
> scheme for this that may or may not be appropriate for others.
>
> 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?
>
> Thanks for this first cut!
>
>      -- Darin
>
> _______________________________________________
> Nautilus-list mailing list
> Nautilus-list lists eazel com
> http://lists.eazel.com/mailman/listinfo/nautilus-list