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? _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
