Proposed draft for the thumbnail D-Bus specification
Philip Van Hoof
spam at pvanhoof.be
Wed Sep 3 08:36:48 PDT 2008
This is what a developer would have to do to make a specialized
thumbnailer. So also for this there's now a prototype:
Note that I used glib for implementing it. That's because personally I'm
used to glib. I'm confident that you can do the same with with QT
libraries. If you want a proof of concept of both the daemon and a
specialized thumbnailer written in QT, you are hereby invited to make
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:
> This is the Subversion repository to a prototype implementation:
> 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, ..
> Features of the draft:
> * Dependency on the Thumbnail-spec (this is definitely a feature, yes.
> Let's start to agree on a common thumbnail storage once and for all
> instead of all inventing our own incompatible thumbnail caches)
> * Queuing and indeed unqueuing requests. This makes it possible to let
> the daemon forget about requests that got requested by accident (the
> use-case being the window of a file manager closing before the
> thumbnailing of items finished) (see lower for canceling)
> * Possibility for the daemon to send early results back for items that
> it could finish sooner than other items. This is useful for already
> cached thumbnails.
> * Possibility for third party vendors to provide a closed source, closed
> or patented format thumbnailer by registering support for a MIME type
> to a manager interface that is required to be implemented by the
> thumbnailer service. Anti-patent feelings are irrelevant for this
> this specification: I don't like patented formats too, but that averse
> is irrelevant here - let's just make it possible and let us make
> others decide for themselves, we are not the anti-patent police -
> Generic thumbnailer: org.freedesktop.manager.Register
> Specialized thumbnailers: org.freedesktop.Create
> * Possibility to queue a lot of items without having to send a lot of
> DBus messages. Possibility for the daemon to reply `Ready` signals in
> groups too (for the same reason).
> * Limited error reporting (I don't think file-managers are going to do a
> lot with errors. But if necessary we can improve error reporting to be
> * Limited status reporting. You receive signals when a queued task is
> started and when it's finished. You receive signals when individual
> items are finished.
> * Intelligent thumbnail handling on Move, Delete and Copy. This allows a
> file manager to inform the thumbnailer about Moves, Deletes and
> Copies. Polling to keep the thumbnail cache correct is not implied by
> this specification (and therefore not required, but permitted).
> Recommended by the specification
> * Asynchronous LIFO handling of the queue (strongly recommended)
> Not supported:
> * Canceling of activated requests. This is too hard to implement.
> Functions like pthread_cancel are a no-option (leaks memory) and
> starting and killing processes is not something I want to require by
> the specification. The only viable option would be to adapt all
> thumbnail algorithms to have meaningful cancel points. This is not
> something I want to require from the specification.
> I also looked at the current thumbnailing code of a few filemanagers.
> Although Nautilus's private library has a load_image_cancel method, it
> doesn't seem to be called (which makes me wonder why it was never
> removed from nautilus-thumbnail.c)!
> Nautilus's remove_from_queue and remove_all_from_queue are however
> used by Nautilus itself. Therefore is this functionality available in
> the D-Bus API.
> * Topnotch status reporting. This is too difficult for implementers of a
> daemon to require in the specification. Just like canceling would it
> require rewriting a lot of thumbnail algorithms.
> Note that the not supported features don't mean that in future it wont
> ever be added to a 2.0 version of this specification or that in a custom
> DBus namespace a thumbnailer can't provide this functionality.
> Philip Van Hoof, freelance software developer
> home: me at pvanhoof dot be
> gnome: pvanhoof at gnome dot org
> xdg mailing list
> xdg at lists.freedesktop.org
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
More information about the xdg