Hi there, This is what a developer would have to do to make a specialized thumbnailer. So also for this there's now a prototype:
https://stage.maemo.org/svn/maemo/projects/haf/branches/hildon-thumbnail/daemonize/tests/daemon.c https://stage.maemo.org/svn/maemo/projects/haf/branches/hildon-thumbnail/daemonize/tests/daemon.xml Note that I used glib for implementing it. That's because personally I'm used to glib. I'm confident that you can do the same with with QT libraries. If you want a proof of concept of both the daemon and a specialized thumbnailer written in QT, you are hereby invited to make one. On Wed, 2008-09-03 at 16:15 +0200, Philip Van Hoof wrote: > Hi there whoever is interested in thumbnailing! > > This is the location to the draft: > > http://live.gnome.org/ThumbnailerSpec > > This is the Subversion repository to a prototype implementation: > > https://stage.maemo.org/svn/maemo/projects/haf/branches/hildon-thumbnail/daemonize/daemon/ > > It's somewhat untested and unfinished and at the same time tested (it's > a prototype at this moment). > > I'm very interested in corrections, reviews, spelling fixes, > concerns, .. > > > Features of the draft: > > * Dependency on the Thumbnail-spec (this is definitely a feature, yes. > Let's start to agree on a common thumbnail storage once and for all > instead of all inventing our own incompatible thumbnail caches) > > * Queuing and indeed unqueuing requests. This makes it possible to let > the daemon forget about requests that got requested by accident (the > use-case being the window of a file manager closing before the > thumbnailing of items finished) (see lower for canceling) > > * Possibility for the daemon to send early results back for items that > it could finish sooner than other items. This is useful for already > cached thumbnails. > > * Possibility for third party vendors to provide a closed source, closed > or patented format thumbnailer by registering support for a MIME type > to a manager interface that is required to be implemented by the > thumbnailer service. Anti-patent feelings are irrelevant for this > this specification: I don't like patented formats too, but that averse > is irrelevant here - let's just make it possible and let us make > others decide for themselves, we are not the anti-patent police - > > Generic thumbnailer: org.freedesktop.manager.Register > Specialized thumbnailers: org.freedesktop.Create > > * Possibility to queue a lot of items without having to send a lot of > DBus messages. Possibility for the daemon to reply `Ready` signals in > groups too (for the same reason). > > * Limited error reporting (I don't think file-managers are going to do a > lot with errors. But if necessary we can improve error reporting to be > topnotch) > > * Limited status reporting. You receive signals when a queued task is > started and when it's finished. You receive signals when individual > items are finished. > > * Intelligent thumbnail handling on Move, Delete and Copy. This allows a > file manager to inform the thumbnailer about Moves, Deletes and > Copies. Polling to keep the thumbnail cache correct is not implied by > this specification (and therefore not required, but permitted). > > Recommended by the specification > > * Asynchronous LIFO handling of the queue (strongly recommended) > > Not supported: > > * Canceling of activated requests. This is too hard to implement. > Functions like pthread_cancel are a no-option (leaks memory) and > starting and killing processes is not something I want to require by > the specification. The only viable option would be to adapt all > thumbnail algorithms to have meaningful cancel points. This is not > something I want to require from the specification. > > I also looked at the current thumbnailing code of a few filemanagers. > > Although Nautilus's private library has a load_image_cancel method, it > doesn't seem to be called (which makes me wonder why it was never > removed from nautilus-thumbnail.c)! > > 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. > > * Topnotch status reporting. This is too difficult for implementers of a > daemon to require in the specification. Just like canceling would it > require rewriting a lot of thumbnail algorithms. > > > Notes > > Note that the not supported features don't mean that in future it wont > ever be added to a 2.0 version of this specification or that in a custom > DBus namespace a thumbnailer can't provide this functionality. > > > -- > Philip Van Hoof, freelance software developer > home: me at pvanhoof dot be > gnome: pvanhoof at gnome dot org > http://pvanhoof.be/blog > http://codeminded.be > > > > > _______________________________________________ > xdg mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/xdg > -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
