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