Re: [GNOME VFS] Re: gnome-vfs API freeze items

Maciej Stachowiak wrote:
On 04Sep2001 06:49PM (+0200), Jens Finke wrote:


On 1 Sep 2001, Jonathan Blandford wrote:

* 8544 - [API] add thumbnail support
    Note: I would personally make this a 2.2 item, but Lutz seems to
    want it. It will almost certainly end up 2.2 unless Lutz steps up
    to the plate with some code soon. :-)

I thought the thumbnail spec being worked on just listed a place where
you could find thumbnails.  I don't see why we need special support in
GNOME-vfs for it?

Digital cameras can provide thumbnails directly. See the bug report. I
don't know if this will really need an API change, maybe the
thumbnails can just magically appear in URI space where the thumbnail
spec specifies (I guess I need to read the thumbnail spec and comment
at some point).

That's what I think makes the most sense.  A separate thumbnail API
seems redundant to me.

I am the author of the current thumbnail spec and want to share my vision
with you here.

The thumbnail spec defines a way how and where to store thumbnails.
Since this became quit complex it involves much more than just loading a
image like  ~/.thumbnails/my-thumb.png (see also the spec at So there is a need for a library
which handles all this stuff and which has a simple API like

Here's a couple of comments on the spec:

* The thubnail spec recommends centralized thumbnails being stored
like this: ~/.thumbnails/96x96/opt/foo/portrait.tiff.png

Instead of making a deep directory structure in ~/.thumbnails, why not
record the path as encoded URIs?

Deep directory structures are slower to access and don't generalize to
non-file: URI schemes (I think the proposed idea of having a directory
named `http:' directory is pretty bad - URIs have a lot of quoting
issues and I think turning them into paths is a bad idea).

The only case I could think of where thumbnails in directories make sense is if you want to browse through the thumbnails

* What if two programs try to thumbnail the same file at once?
Shouldn't there be some kind of locking?

* Permissions on homedir stored thumbnails probably should not follow
the algorithm for giving group and other write permissions.

And for public thumbnails, the .thumbnails dir should have the same permissions as the parent dir, and the thumbnail should have the same permission as the original file.

thumb_factory_request_thubmnail (gchar *image_path)

It then would try to find exisiting thumbnails or creates a new one if
neccessary. If any gnome program needs to implement this functionality
seperately this would result in unneccessary code duplication.

First, it would be nice to take a URI rather than a path.

Second, it would probably be useful to have some kind of async
interface for thumbnailing as well, since thumbnails may be on a
remote filesystem, and since even if it's local, generating a
thumbnail can be a slow operation (if the image is really huge for
instance, or if you are using a plug-in thumnbnailer for a slow to
render type).

I would suggest just using regular programs rather than bonobo for
thumbnailing because there's no real need for rich IPC here - you just
tell the program "thumbnail this image and dump it here" (or you could
pass it a set of images and a location to dump them, dunno). If there
happens to be a bonobo component that's good for thumbnailing, you
could easily write a thumbnailer program that would call it. And for
some image types, you could easily use ImageMagick with appropriate
command-line options as a thumbnailing program.

The broader vision for this is to support not only image thumbnails but
also previews for HTML, PDF, text or other filetypes (based on mime-type
identification and a plug-in system, maybe through bonobo). Anyway, I am
currently working on a seperate library, which supports all this (at least
for simple images). Since I don't want to add yet another library to the
gnome platform I think something like gnome-vfs could be the right place
if my work is matured enough.

gnome-vfs really should not depend on gdk-pixbuf, but other than that
it would be nice for it to have more sophisticated icon support.


/Bastien Nocera

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]