Proposed draft for the thumbnail D-Bus specification
Philip Van Hoof
spam at pvanhoof.be
Tue Sep 9 15:46:14 PDT 2008
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?!
Just to flood the DBus system with pixbuf data?
Previews and thumbnails can of course be in the same library. For the
thumbnails you can ask the central service, for previews just use the
same scaling techniques your library uses to rescaling the thumbnail to
its final size.
if (size < 256)
use thumbnail service
on service's callback
use rescaling code on thumbnail
use rescaling code on original
The reason why not "use rescaling code on original at size" are:
- Rescaling a large file takes longer
- There's good a chance that you get an exact size (if your app uses
the preferred thumbnail sizes, as specified by the thumbnail-spec)
- Local availability of remote file's thumbnails
- No duplicate disk-space for applications that are caching the same
type of data
- Delegation of thumbnailer work to specialized pieces of software that
probably know better how to thumbnail specific MIME types than that a
cloud of desktop applications would each individually know
- Dependency problems (desktop applications linking with various image
libraries, just for the sake of requesting the generation of a
- No more need for applications to implement their own asynchronous
LIFO queue for generating thumbnails
- Less processes and threads (as generating a thumbnail is usually to
be done in either a process or a thread, as most algorithms are not
integrated with either GMainLoop nor QT's mainloop - if the QT being
used ain't integrated with GMainLoop -)
- I can come up with a lot more reasons ...
> HOWEVER, a thumbnail _service_ should be able to provide such large
> previews without storing them on disk, i.e. completely unrelated to
> the thumbnail-on-disk-spec.
> Either I'm missing something here, or a dbus thumbnail service that
> would be limited to small thumbnails, would be of rather limited
The point of the service *is* to manage the cache as defined by the
No matter how limited of use that is.
> (what's the point of switching to something that would only do half of what we need...)
The point of using the thumbnail-spec is written on that spec. I also
gave a few reasons higher in this reply.
But ... I don't want to keep defending the purpose of 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.
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
More information about the xdg