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

[Bastien Nocera <hadess hadess net>]

Maciej Stachowiak wrote:
> 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).

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.

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

Nod.
Cheers

--
/Bastien Nocera
http://hadess.net