Review of the thumbnailer spec
jannis at xfce.org
Mon May 18 07:01:27 PDT 2009
On Mon, 18 May 2009 13:48:08 +0200
Philip Van Hoof <spam at pvanhoof.be> wrote:
> On Fri, 2009-05-15 at 04:00 +0200, Jannis Pohlmann wrote:
> > In theory, this should completely hide how thumbnails are stored.
> > For instance, it doesn't really matter whether a cache is used or
> > not. It doesn't even matter where the thumbnails are stored.
> That is correct, except of course that a consumer will need to know
> about the thumbnail-spec (the storage one) to know where he can find
> the thumbnails when they are ready. Or where he can find the failures.
> It's however the case that for our use-case (Nokia's devices) we are
> only interested in cropped, not large nor normal, and that we want to
> store thumbnails as JPeg files, not PNG.
> So we believe that the storage specification for thumbnails isn't
> complete or rather isn't flexible enough.
Possibly. One part of the thumbnail spec I'm not exactly happy with is
that failed thumbnails are stored per application. This means that e.g.
for G_FILE_ATTRIBUTE_THUMBNAIL_FAILED, GIO has to use hard-coded fail
paths (right now it only checks fail/gnome-thumbnail-factory/).
> > Of course this raises the question how the interfaces should be
> > named. Should it be org.freedesktop.thumbnailer.* or
> > org.freedesktop.thumbnails.*, or even a mixture of both? Should it
> > be org.freedesktop.thumbnailer.Cache or .CacheManager?
> > Also, the name .Generic is rather undescriptive. I'm pretty sure
> > we there's a better name for this. Let me throw .Provider, .Service
> > or .Delegate in the pot as a few of my first ideas.
> How about :
> - Queue
> - Unqueue
> - Ready
> - Error signal
> - Finished signal
> - Started signal
Having everything under org.freedesktop.thumbnails makes me wonder what
to do about org.freedesktop.thumbnailer.Thumbnailer which is used for
specialized thumbnailers. I guess it would be better to move them all
into the same namespace and name them differently (not using
Thumbnailer twice). Thoughts?
> - Move
> - Copy
> - Cleanup
As a consequence of the above I'm wondering about a new method called
Failed(). But even that doesn't really solve the problem of where the
failed thumbnails are stored of course.
> - Register
> - GetSupported
I'm thinking about the situation where manager and generic thumbnailer
are implemented as separate daemons. In that case we'd probably want
additional methods like this one:
- GetThumbnailers (returning the D-Bus names of all registered
And maybe a signal
- Registered() (including the D-Bus name of a newly registered
Right now the manager is only useful if it's implemented in the same
process as the generic thumbnailer.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 197 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20090518/f9ceeb64/attachment.pgp
More information about the xdg