Proposed draft for the thumbnail D-Bus specification

[Philip Van Hoof]

On Tue, 2008-09-09 at 12:46 +0200, David Faure wrote:
> On Tuesday 09 September 2008, Philip Van Hoof wrote:
> > But I don't want to require process-based by specifying the possibility
> > of canceling an active task.
> 
> Sure, I don't think it should be required, but I think it should be possible.
> Otherwise it kills any hope of KDE switching to such a spec.

Okay. Feel free to send me a proposal for cancels then.

> > Previews are not thumbnails ...
> 
> That's a distinction I don't understand :)
> We use kio_thumbnail in PreviewJob, so obviously for us there is no such distinction.
> What distinction do you make?

> I thought we were talking about the use cases like "the icons in my file manager
> look like the contents of the files" (as well as the less common "the tooltip shows
> a bigger version of it" which we do as well, using the same backend).
> I assume you allow the application to request the size it wants?

No, the thumbnail-spec only mentions two sizes. This specification is
only for managing the cache in "thumbnail-spec".

http://jens.triq.net/thumbnail-spec/

The resize to the final size that the application is going to require,
is something a library on top of the specification is responsible for.

What most thumbnailers do is pick the best-fit thumbnail and resize that
to the final size (for example in memory).

Quick example:


static void on_thumbnails_ready (DBusGProxy *proxy,
				const gchar **uris,
				gpointer user_data)
{
  MyClass *self = user_data;

  unsigned int i = 0;
  while (uris[i] != NULL) {
    GdkPixbuf *pixbuf;

    char *small = get_thumbnail_path (uri);
    GFile *file = g_file_new_from_path (small);
    GInputStream *stream = g_file_read (file, NULL, NULL);

    /* This is the final resize */
    pixbuf = gdk_pixbuf_new_from_stream_at_scale (stream,
		100, 100, TRUE,  NULL, NULL);

    /* Render the pixmap (assign to a GtkImage) */
    my_class_put_pixbuf_at (self, pixbuf, uri);

    gdk_pixbuf_unref (pixbuf);

    g_input_stream_close (stream);
    g_object_unref (stream);
    g_object_unref (file);

  }
}

static void
my_class_init (MyClass *self)
{
   DBusGProxy *proxy = org.freedesktop.thumbnailer.Generic

   dbus_g_proxy_connect_signal (proxy, "Ready",
       G_CALLBACK (on_thumbnails_ready), NULL, self);
}

static void
my_class_on_i_need_to_render_a_screen (gchar **uris_to_render)
{
   char **uris = uris_to_render;

   uris[0] = strdup ("file:///home/user/Screenshot.png");

   org_freedesktop_thumbnailer_Generic_queue_async (proxy, 
         (const char **) uris, 0, NULL, NULL);
}


A preview is usually a lot larger than a thumbnail. Although you could
take the largest-sized thumbnail out of thumbnail-spec and resize that
for files that don't have a quick-preview technique (unlike jpeg).

In the spec you'll see Queue and Unqueue. You wont see: Queue for this
size. That also doesn't make a lot of sense "for managing the caches of
thumbnail-spec": The "thumbnail-spec" has "large", "normal" and "fail":
Large for the large thumbnail, normal for the normal thumbnail and fail
for failures. It doesn't have a folder for each ever requested final
resolution. No, your application (the library on top) must take the
best-fit thumbnail and do a final resize instead.

Other than using the largest thumbnail and resizing that to the preview
size, I don't see how that correlates to previews.




-- 
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://pvanhoof.be/blog
http://codeminded.be