Proposed draft for the thumbnail D-Bus specification

David Faure dfaure at
Wed Sep 10 04:44:51 PDT 2008

On Wednesday 10 September 2008, Philip Van Hoof wrote:
> We already discussed this and you seem to have replied that only adding
> ints and a bool is the right solution.

No, I only suggested adding parameters because you didn't want to hear about the
proper two-layer solution because that was too much work. So I tried to find
a solution that was closer to your design, but it is certainly not my preferred solution.
When I presented the KDE design, I thought it was clear that I was advocating this
kind of architecture.

> Now, about splitting the service:
> This doesn't change the current org.freedesktop.thumbnailer.Generic
> interface (I'm only talking about the interface, not the implementation)


> It would only require changing the interface of the specialized
> thumbnailers. Instead of just "Create" without a return value, it would
> have to return a key to a SHM.

Yes (although we might want a fallback solution for the case where SHM is not
available, like actually passing pixmap data over the wire, unless you have a better

> Therefore, can we continue with further specifying the Generic interface
> and later fine tune the specialized thumbnailer's interface?

Hmm, ok, although I fear "later" is "never" in this kind of sentence :-)
For anything to work you need both interfaces.

> If people really think there's sanity in starting two different
> specifications: one for generic resizing (and for playing the role of
> the plugin interface for the thumbnailer infrastructure), and one for
> generic thumbnailing (consuming the generic resizing spec to write to
> the cache as specified by thumbnail-spec), then I *am* all for it.

Me too (except that I still don't like the term "resizing" -- making an image
that shows the first few lines of a text file is not "resizing" that text file...).
I can only suggest "preview" as a better term, but I'm open to suggestions :)

> > Not at all, you're the one doing that!
> > I presented a design with two layers:
> >  * upper layer: thumbnail-spec handling
> >  * the layer below: data-to-image previewing
> No, you presented a design with two ints and a bool. I laid out the two
> layer design ... 

I suggest to re-read the email where I presented the KDE design ;-)

> but it doesn't matter. Let's continue. 


> > Can we please stick to the problem at hand instead of deriving into nonsense?
> Relax, rhetoric is fun sometimes. It wakes people up.

Sorry, I don't find rhetoric fun - I am under stress from tight deadlines to hold
and I'm trying to minimize the time I spend on this (longer than I would wish, but
now useful again it seems) discussion.

> Obviously I didn't intent to say that your proposal is indeed like a
> Universe class. I just wanted to point out that if we indeed want what
> you require, that we need to do it multi-layer instead of "just add two
> ints and a bool".

OK. See, explicit sentences are better understood than rethoric.

> I'm first going to further test, fine tune and continue with the
> org.freedesktop.thumbnailer.Generic interface, and I will rethink the
> org.freedesktop.thumbnailer.Thumbnailer interface for specialized
> tbumbnailers.
> If the SHM proposal of yours is too difficult for average thumbnailer
> coders to implement, then we'll have to find proper solutions to reduce
> that complexity.

Right. What we do in kio_thumbnail is that the SHM stuff is handled by the
generic code, while the mimetype-specific plugins only have to create
an image (in memory) from a given file.
In terms of your design I think this would mean a generic previewer :-)
So, generic thumbnailer --> generic previewer --> specialized previewer.
(--> means "uses").

And both generic thumbnailer and generic previewer provide a standard dbus
interface, so it's possible for applications to access either one directly.

Specialized previewers don't have to be separate processes (ideally it's
rather an in-process plugin for the generic previewer), but can be.

> For example:
> How do you support writing a thumbnailer that wants to fork(); execv() a
> ImageMagick binary like "convert"? You make it write in /tmp, and read
> in the entire imagine into a SHM?
> Because that's a lot less efficient than how a current specialized
> thumbnailer would be: the requirement to read the file into SHM is
> implicit in this multi-layer proposal, for such implementations of
> resizers (or thumbnailers).

Right. Both layers of communication (specialized previewer --> generic previewer
and generic previewer -> generic thumbnailer) have to support multiple communication
mechanisms, to avoid this problem.
* passing the pointer (if same process, which is the ideal solution for specialized previewers...)
* path to a file
* passing pixels (maybe we can do without this one, if we use tempfiles, with always
the problem of "who is deleting the tempfile").

David Faure, faure at, sponsored by Trolltech to work on KDE,
Konqueror (, and KOffice (

More information about the xdg mailing list