[Kde-imaging] extragear/graphics/kipi-plugins

Gilles Caulier caulier.gilles at gmail.com
Mon Dec 1 10:16:32 CET 2008


2008/11/29 Aurélien Gâteau <aurelien.gateau at free.fr>

> > Aurélien,
> >
> > As i said to coding sprint, I'm working to a new batch queue manager for
> > digiKam. A first preview is available on my flickr account :
> >
> > http://www.flickr.com/photos/digikam/3065212027/sizes/o/
> >
> > Like you can see on the bottom of Queue manager window, i plan to plugin
> > all kipi batch tools here. For the moment, it's limited to use internal
> > tools from digiKam core.
> >
> > This is want mean that later libkipi need to be patched in this way. But
> > it's not for the moment (:=)))
>
> Oh, yes I remember now. Just to make sure we are talking about the same
> thing: The idea is to be able to write a new type of  KIPI plugins,
> which would be able to work on image data and have the host app
> implement a batch manager which can call these plugins. Is that it?


yes; but plugins structure is just adapted to export batch core component
only to host.

Currently, my batch Queue manager use core libs from digiKam, where a lots
of code can be used to play with image data (color corrections for ex.)

I have implemented a definition of Batch Tools like tis :

input image path
+                          -> Batch Tool -> output image path
tools settings

The Batch tool component export settings in a class container + a widget
where settings can be adjusted by user in Queue Manager.

My idea for the future, is to adjust batch tool plugins in this way: we
export batch core implementation + settings widgets + settings data to use
it somewhere in host application....

The advantage of Queue Manager is to be able to process more than one batch
action at the same time. Batch tools can be serialized one by one.

Also, in the same time, we must preserve the current Batch tool plugin
dialogs, in case of host cannot play with the new Batch Tool interface. Of
course, in this case, plugins can only process one action by images.

My plan in first is to implement a version using digiKam core components,
and hack,improve, and polish Batch Tools interface to  proposal a new
libkipi extension. This will be for later KDE 4.2, when kipi-plugins 0.2.0
and digiKam 0.10.0 final releases will be published.

best

Gilles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-imaging/attachments/20081201/ad68f488/attachment.htm 


More information about the Kde-imaging mailing list