A Standard for Thumbnailers
E.R.M.Davidson at sms.ed.ac.uk
Thu Jan 11 10:15:36 PST 2007
Pat Suwalski wrote:
> Stanislav Brabec wrote:
>> 0. Try to embed thumbnail into the file, which supports it, if user
>> explicitly wants it.
>> 1. Try to use xattr or resources, if file system supports it and it
>> allows large enough data (may fail often)
>> 2. Try dotted local directory (may fail on FAT)
> Once again, this is a terrible idea. It's where Microsoft got it wrong
> with the hidden Thumbs.db. Extremely awkward when copying directories
> around. There should never be any extra baggage around my files.
Storing the thumbnails on the volume is the only safe way to produce
thumbnails for encrypted devices (see below). It has it's advantages too
- they don't have to be regenerated on each machine using the volume, so
you trade a little disk space for cpu cycles.
> It is already hugely annoying that "deleting" a file on my camera in
> Nautilus moves it to some hidden Trash directory on the memory card.
It is a bit, but there is no other way of having a trash folder for
removable media and not posing a threat to security for encrypted
devices. Sure a thumbnailer could try and detect an encrypted volume and
just turn off thumbnailers... but how would you futureproof that? In
five years time folk might not be using cryptsetup-luks. Even if you get
in-kernel support for this (i.e. a list of encrypted volumes in /sys/ or
a new mount option: "no-thumbnail") that doesn't interoperate too well:
the bsd folk might want to use the thumbnailers.
>> 3. Try another specified directory (may fail on read only)
>> 4. Fall back to global user cache in ~/.thumbnails
> xdg mailing list
> xdg at lists.freedesktop.org
More information about the xdg