Proposed draft for the thumbnail D-Bus specification

[Alexander Larsson]

On Wed, 2008-09-03 at 16:15 +0200, Philip Van Hoof wrote:
> Hi there whoever is interested in thumbnailing!
> 
> This is the location to the draft:
> 
> http://live.gnome.org/ThumbnailerSpec
> 
> This is the Subversion repository to a prototype implementation:
> 
> https://stage.maemo.org/svn/maemo/projects/haf/branches/hildon-thumbnail/daemonize/daemon/
> 
> It's somewhat untested and unfinished and at the same time tested (it's
> a prototype at this moment).
> 
> I'm very interested in corrections, reviews, spelling fixes,
> concerns, ..

I just did a quick scan of this. Here are some comments:

The use of URIs as argument to the thumbnailer is problematic in many
respects. For instance, URIs means different things to different
desktops (gnome-vfs uris, gvfs uris, kio uris, apps manually handling
http uris). They support a different set of uris, they authenticate
differently, they don't share active connections, etc. 

I mean, how exactly is this mean to work if i'm writing a kio based file
manager and send over a uri to e.g. a gio/gvfs based thumbnailer
service? 

Also, having each specialized thumbnailer handle the uri getting means
you push this even harder. What if some specialized thumbnailers use gio
and others kio? An alternative would be for the common code to download
the file and pass a local path to the thumbnailer, but then you get
problems with file types with large files that you only need to load a
part of to thumbnail (for instance movies).

I don't have any answers here, just pointing out problems. Of course,
this is generally only problematic if you try to make this a
cross-desktop standard. Otherwise you can just say "uris are gvfs uris"
or whatever.

For nautilus, what I do is queue all the thumbnailable files in the
directory for thumbnailing, but then I prioritize the files that are
currently visible. So, when you scroll all the newly showed files are
pushed to the top of the queue. This seems much better than queueing
just the visible files each time you scroll, as then the non-visible
icons won't be thumbnailing in the background waiting for you to scroll.

I don't like that the service errors out if any one file in the
requested set fails to thumbnail. You don't even know which one failed.
This is useless. I still want to thumbnail all the other files that are
thumbnailable. A better solution would be to write out a failed
thumbnail (as per the spec) and then call either Ready with a boolean
success argument or a separate Failed signal.

Also, wrt failed thumbnailings. What id should be used to look for
failed thumbnailings?