Proposed draft for the thumbnail D-Bus specification

[David Faure]

On Wednesday 10 September 2008, Philip Van Hoof wrote:
> On Tue, 2008-09-09 at 23:22 +0200, David Faure wrote:
> > On Tuesday 09 September 2008, Philip Van Hoof wrote:
> > > Well, the thumbnail-spec allows to put nearby sizes in either large
> > > or normal 
> 
> > This is my main issue with all this. The thumbnail-spec is about what
> > gets cached onto the disk, right? Of course it wouldn't make sense to
> > store 200x200 pixmaps of every file you moved the mouse over.
> 
> If it's not a cache nor a central kind thing, why make it a service
> rather than a library?!

Service or library doesn't matter, what matters is to need only one implementation
of the data-to-image code for each type of data. If I write an EXR thumbnailer, which
has all the code for reading a big EXR image and generating a pixmap out of it at
any size, why shouldn't I be able to use that code even when generating larger previews?

Your suggested algorithm below...

> if (size < 256)
>   use thumbnail service
>     on service's callback
>       use rescaling code on thumbnail
> else
>   use rescaling code on original

... assumes that we can just get the "original" as an image. But isn't that the whole point
of the service we're talking about, to have the implementation for original-to-image?
So the "else" branch also needs that service.

Otherwise we could be talking about a simple service that loads/stores small PNGs into the
on-disk thumbnail cache, but then I don't see the point in mimetype-specific plugins for it.
If such plugins exist, then they should also be useable for generating larger previews,
otherwise that code is just going to be duplicated, which is never a good idea.

> Just to flood the DBus system with pixbuf data?

We use SHM where available in KDE, to solve the issue of the amount of data
being transmitted over the wire.

> The point of the service *is* to manage the cache as defined by the
> thumbnail-spec, indeed.

That would be fine, but I don't think this is what you started specifying, since
it also manages data-to-image conversion plugins on top of it, but limiting
those to the thumbnail spec.

> This DBus specification *is* about remotely managing the thumbnail-spec.
> If that specification ain't useful for your purposes, I guess this DBus
> specification ain't going to be useful either, indeed.

I think you misunderstand me slightly. The thumbnail-spec is fine as far as 
I'm concerned; but it's "just" about caching, nothing else.

I'm just saying that on-disk caching
(as covered by the thumbnail-spec) isn't the only thing one should be considering
when talking about writing code that can convert anything to images.

OK after a bit more reading I now realize that "large" is 256x256 in the thumbnail spec
and that's exactly what konqueror & dolphin use for the big preview in the tooltip, 
so "larger previews" isn't such a convincing use case (at least for those apps),
let me talk about another one: generating a preview for a temporary file, 
i.e. disabling caching because we know the file is going to be thrown
away, so there's no point in storing the resulting thumbnail on disk.


What I'm trying to say with all this is: in KDE we have the following design:
*  PreviewJob (available in the KIO library) handles the thumbnail spec, and when it
doesn't find something in the cache, it requests a thumbnail of a specific size.
* That request goes to kio_thumbnail, which itself has mimetype-specific plugins
for converting anything to images. [kio_thumbnail has support for drawing a frame 
around the preview, and support for blending the mimetype icon over the 
generated preview, at the plugin's request].

PreviewJob has API for letting the application decide whether the resulting thumbnail
should be saved for later use or not. It also supports skipping files that are too big
(based on a user-configurable value). There is full control over what happens, because
all the logic is in the higher level, while the low level is a stupid file-to-image converter
[with parameters including max width and height]. 

It seems to me that your suggested spec is architectured the other way round:
the low-level file-to-image service also handles the thumbnail-spec, which means
there is no way to request a preview at a specific size, or to request a preview without
storing the result into the on-disk cache.
But all this seems fixable by simply adding a way to specify a size, and whether to save the resulting image.
Just two ints and a bool after all :-)

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).