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

[Maciej Stachowiak <mjs noisehavoc org>]

On 04Sep2001 06:49PM (+0200), Jens Finke wrote:
> Hi,
> 
> 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
> http://triq.net/~pearl/thumbnail-spec/). 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).

* 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.


> GdkPixbuf*
> 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.

 - Maciej