Proposed draft for the thumbnail D-Bus specification
David Faure
dfaure at trolltech.com
Wed Sep 10 02:16:44 PDT 2008
On Wednesday 10 September 2008, Philip Van Hoof wrote:
> On Wed, 2008-09-10 at 01:27 +0200, David Faure wrote:
>
> I think instead of org.freedesktop.thumbnailer you want a pluggable
> org.freedesktop.imageresizer namespace.
This is not about resizing only! Again, the input data could be any of kind of file,
not just images. This is about a "make a thumbnail of this file at width x height" service,
let's not play on words.
> Thumbnailing is not generic resizing of images (without even storing
> it), if you just resize an image and don't store it .. it's called
> resizing. period.
This is a very limited view - the input for a thumbnailer/previewer isn't only images.
There is a need (and an implementation in kde) for thumbnailing/previewing
images, but also plain text, HTML, OpenDocument files, SVG, and more.
The service that provides a PNG out of those is not to be called resizer, but thumbnailer.
> If you indeed set up that specification and if you make a desktop
> neutral prototype and it indeed becomes part of freedesktop, I'd be
> happy to let this org.freedesktop.thumbnailer.Generic use the
> specialized resizers in org.freedesktop.imageresizer instead of its own
> specialized thumbnailers in org.freedesktop.thumbnailer implementing
> org.freedesktop.thumbnailer.Thumbnailer.
Yeah sure, reply with "you do the work" to make sure you win because I don't
have time for this. There is no need for a separate imageresizer service,
all we need is a bit more flexibility in the thumbnailer service.
> The org.freedesktop.thumbnailer.Generic getting a SHM from the elected
> specialized resizer, and then the thumbnailer storing the resized pixbuf
> as specified by the thumbnail-spec, and signaling the `Ready` signal.
Yes. With s/resizer/thumbnailer/ ;)
> Regretfully I didn't start with an existing org.freedesktop.imageresizer
> being available.
No, but you're specifying the thumbnailer service which will have the
data-to-image code, and that's exactly what this theoretical imageresizer
would be anyway. Don't do a "SEP", it's not true.
> My POV is that current freedesktop's DBus APIs don't go that far yet,
> perhaps with the exception of richer frameworks like Telepathy, and
> although the idea fits my view of taking over the world, I fear this
> wont happen in time. Maybe in a few years we will have this, indeed.
>
> But if nobody is hungry for specifying a o.f.imageresizer, let's stay
> with our both feet on the ground and start modest with just a namespace
> like o.f.thumbnailer.
In this case "modest" == useless. Sorry.
You're making this a freedesktop.org specification in order for this to be shared
among desktop environments, no? Why then
1) ignore actual working implementations of this?
2) ignore comments from people who know those implementations?
I can see yet another gnome-only freedesktop spec coming up, if it is made
less useful than kio_thumbnail :(
--
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
More information about the xdg
mailing list