Hi,
as you might know we are implementing the proposed Thumbnail Managing
Standard for GIMP 1.4 (see http://triq.net/~pearl/thumbnail-spec/).
Mitch and me have sent this mail to the free desktop mailing-list
today. I'm forwarding it here just in case someone wants to join the
discussion...
--- Begin Message ---
Hi,
while implementing the Thumbnail Managing Standard we stumpled across
a few things that might need to be reconsidered:
Version 0.5 of the standard says:
"If a program needs a thumbnail for an image file which is smaller than
128x128 pixel it doesn't need to save it at all."
We don't think this is a good idea since the image might contain a
whole lot of layers. Reloading the image each time a thumbnail is
needed is not an option in this case. Also a filemanager or image
viewer might want to display a thumbnail of a small XCF image (for
example) even though it can't open the format directly. Reusing a
thumbnail that GIMP created would solve this problem.
This change brings up another missing point, what about thumbnails of
thumbnails? The standard should specify clearly that no thumbnails
should be created for URLs that contain the word ".thumbnails".
Otherwise a thumbnail generator might easily go into a recursive
loop when it is called inside the ~/.thumbnails directory.
We also think that the thumbnails should be split up into
subdirectories in order to avoid problems with too many files in one
directory. A typical user might nowadays easily have several thousands
of thumbnails. Most filesystems don't cope well with such large
amounts of files in one directory. Our proposal is thus to introduce
subdirectories specified by the first letter of the thumbnail name.
That would give 64 subdirectories and the thumbs should evenly
distribute between them. So, for example a 128x128 sized thumb for
~/photos/me.png would be stored into
~/.thumbnails/normal/c/c6ee772d9e49320e97ec29a7eb5b1697.png
Also, the standard should probably be less strict when it comes to
thumbnails that may be out of date. Currently the standard forbids to
use a thumbnail that is outdated or might be outdated. We think that
it should be allowed to present such a thumbnail to the user if the
fact that the thumbnail is outdated or maybe outdated is clearly
indicated. Such an indicator might be a label below the thumbnail
saying "Thumbnail [is|may be] outdated". The user can then choose to
regenerate the thumbnail. This will allow applications to display
thumbnails for remote images that it finds in the .thumbnails dir
but for which it is unable to determine the modification time. Also
an image viewer might want to give the user the choice to disable
automatic thumbnail generation. It could then at least display
outdated thumbnails and mark them as such somehow.
Please comment on this proposals.
Sven Neumann, Michael Natterer
_______________________________________________
Xdg-list mailing list
Xdg-list@xxxxxxxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/xdg-list
--- End Message ---
