Proposed draft for the thumbnail D-Bus specification
Philip Van Hoof
spam at pvanhoof.be
Thu Oct 16 14:35:15 PDT 2008
On Fri, 2008-10-10 at 11:40 +0200, Alexander Larsson wrote:
> On Fri, 2008-10-10 at 11:26 +0200, Alexander Larsson wrote:
> > On Wed, 2008-09-03 at 16:15 +0200, Philip Van Hoof wrote:
> > For nautilus, what I do is queue all the thumbnailable files in the
> > directory for thumbnailing, but then I prioritize the files that are
> > currently visible. So, when you scroll all the newly showed files are
> > pushed to the top of the queue. This seems much better than queueing
> > just the visible files each time you scroll, as then the non-visible
> > icons won't be thumbnailing in the background waiting for you to scroll.
> Oh, and while talking about nautilus. I'm not sure this is very
> interesting for us to use. I don't see any advantages with this compared
> to what we already have (its the same, just via dbus), and it seems
> limited in scope compared to what we eventually want (like larger
> previews in a preview pane).
What I was having in mind for Nautilus was not to be a consumer, but
rather be a provider of the service.
That way whenever a consumer would ask for a thumbnail, it would be
Nautilus that would fulfill it.
Nautilus is among the resident processes on most people's GNOME desktop
that already have all the code for thumbnailing running. That's why it's
also a good candidate for becoming the service (on a desktop).
Of course would Nautilus in case of having to compete for the DBus
service need to be forgiving for the competitor. So if two implementers
want to be service, then only one can eventually be in charge and carry
the burden of having to make thumbnails for other softwares.
But Nautilus could of course register its own thumbnail plugins as
separate Thumbnailer plugins for the service-that-is-in-charge too.
The KDE people reading this can replace "Nautilus" with the filemanager
software for KDE. Or with "a separate daemon" (or whatever).
This specification doesn't imply nor specify the eventual implementation
or architecture itself. Of course.
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
More information about the xdg