[Digikam-devel] External tools

[Gilles Caulier]

2013/10/25 Yuri Samoilenko <kinnalru at gmail.com>

> Hello
>
> I want to implement "External tools" feature(as in kate was), and I
> already take look at digikam software compillation sources.
> Feature must allow to use custom script(external) to operate with image
> files. For examplt to create solid archive file with currently selected
> images.
>  As see it is a 3 ways to implement such feature:
> 1. as batch tool
> advantages:
>  - easy to implement(simple BatchTool API - inherit BatchTool class and
> implement toolOperation as for example croptool does)
>  - settings and settingswidget factory out of the box
> disadvatages:
>  - is it possible to embed batch tool to context menu (right mouse click)?
>
> 2. as kipi plugin
> advantages:
>  - settings and settingswidget factory out of the box
>  - context menu integration out of the box
> disadvatages:
>  - little more complex kipi plugins API
>  - breaking semantics(as I think) of "image manipulation"... is for
> example 'creating archive' appear to be 'image manipulation'?
>
> 3. directrly embed to context menu like "open with" and other actions
> advantages:
>  - i don't know
> disadvatages:
>  - i don't know how to implement
>
> What do you think about this?
>

None of these 3 solutions are the best.

A BQM tool is problematic. If you take a look, you will see that all tool
workflow use Digikam::DImg container to process images. A BQM tool is to
process one items, not more than one at the same time (to make tarball for
ex).

A kipi-plugins is problematic because it's a stand alone operation, where
you want to do it and end of BQM workflow. Typically Batch operation from
kipi-plugins migrate to digiKam BQM, because all can be serialized in one
workflow, ans saved to be reprocessed later. You cannot do it with
kipi-plugins.

With kipi, we have this problem with all export tools which are a stand
alone processing in a dedicated dialog.

A solution can be to export kipi tool settings + core operations to kipi
host application, but this need to change a lots libkipi API and patch
whole plugins. Typically, a student have been planed to work a ths project
with GSoC, but he have found a real job and project have been canceled. See
details here :

https://community.kde.org/GSoC/2013/Ideas#Project:_Integrate_KIPI_Export_Plugins_directly_in_the_GUI_of_KIPI_host_applications

The KDE service way is too... limited and cannot be serialized in BQM.

My proposal is more simplest : In BQM, patch Queue "Target" settings to
include new options to perform "export features". This can include tarball
processing, export to a remote computer, export to a web service, etc..

Best

Gilles Caulier
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-devel/attachments/20131025/21ea52e8/attachment.html>