Proposed draft for the thumbnail D-Bus specification
Philip Van Hoof
spam at pvanhoof.be
Tue Sep 9 03:30:54 PDT 2008
On Tue, 2008-09-09 at 11:02 +0200, David Faure wrote:
> On Wednesday 03 September 2008, Philip Van Hoof wrote:
> > 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.
> You assume a thread-based implementation of the tumbnailer.
But I don't want to require process-based by specifying the possibility
of canceling an active task. And killing processes is not a technique
that I want to require, either.
Some devices don't even have a lot of processes. The programming
technique for those mobiles is to run as much as possible in one big
application (one process) ... how would requiring a technique like
killing processes work for those people? It wont.
I would perhaps accept an amendment to the specification mentioning the
possibility of canceling *some* of the thumbnailers's tasks. Without any
guarantees for success.
But I wont accept a amendment that requires the success of a cancel, as
that makes the specification impossible to implement for some groups of
people. Rendering the entire document irrelevant for them.
For example GdkPixbuf. These two have a GCancellable instance:
This means that you can do g_cancellable_cancel (cancel) to what you
passed, and it should cancel the loading-from-stream. But looking at the
implementation it doesn't look like it can be canceled during the
scaling itself (for GdkPixbuf::new_from_stream_at_scale). Not sure,
That's only, I guess, because GIO and GVFS have interesting cancel
points in the read() implementation of GFile. I'm not sure if all GIO
streams are required to have interesting cancel points in their read()
implementations. I can imagine not.
Some thumbnailers (for example for various video formats or other
formats) might not make canceling possible either.
> KDE uses a process-based implementation, and therefore canceling activated requests
> is most certainly doable
Sure, that's very good for KDE and I'm glad for you guys. But I still
won't require that technique by specification.
Keep up the good work, though!
> - and needed for better user interaction indeed; e.g. if previewing
> a huge image takes a lot of time and RAM, the user can just abort previews by pressing
> Esc or the stop button in the filemanager.
Previews are not thumbnails ...
> Or with the preview in a tooltip, we certainly
> don't want to be doing 100 useless previews for files which the tooltip was on, but isn't
> on anymore, while moving the mouse.
> David (who wishes he had more time for looking more into this spec)
Take your time. I understood you are involved in KDE's file manager so I
do value your input a lot obviously.
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
More information about the xdg