we should really move this discussion to xdg-list.

Bryan Ford <[EMAIL PROTECTED]> writes:

> While thumbnails aren't necessarily ephemeral, they certainly are
> automatically regenerable - it is the standard behavior for all
> applications I know of that use them to regenerate them
> automatically if they disappear for any reason.  Sure, the original
> source material may be on removable media, so some of the thumbnails
> won't actually be _regenerated_ until the user inserts that
> particular CD-ROM and browses it again.  But even if those
> thumbnails hadn't been lost, they wouldn't ever be used until that
> point anyway.  Since the thumbnails are effectively useless until
> and unless the original content re-appears, and they can be
> regenerated from the original content once it does re-appear, I
> can't see how their storage matters beyond the performance penalty
> of having to re-compute the thumbnails from scratch.  And that's the
> definition of a cache: if you lose it, you wait longer for stuff to
> load next time, but it's not disaster.

The point I was trying to make is that thumbnails are _not_
automatically regeneratable, at least not by the applications reading
them. There are a couple of file formats that only certain
applications understand (such as for example the GIMP XCF format).
A file-manager doesn't know how to create a thumbnail for these file
formats. It still can use the thumbnail that the application which
created the file (GIMP in this expample) wrote to the .thumbnails
directory. That's the whole point of the Thumbnail Managing
Standard. If the .thumbnails directory is being deleted (or lost in a
disk crash), vital information is lost which cannot easily be
regenerated. I'd call that a disaster and thus vote for explicitely
not tagging the .thumbnails directory as a cache directory. It simply
isn't one.

> > Since GIMP doesn't put swap files into a dedicated directory your
> > proposal will also not work for GIMP swap files (which are admittedly
> > not worth to be archived).
> I had thought that that was what the ~/.gimp-2.0/tmp directory was
> for, but on re-running the GIMP I see that I was mistaken.  So
> you're right - in order to adopt the proposed convention for its
> tile cache, the GIMP would have to make an additional subdirectory
> and move its swap file into there.

We could very well do that but it is nevertheless a weak spot in your
proposal and I suggest that you think about ways to tag individual

Gimp-developer mailing list

Reply via email to