new plugins interface for 6.0.0

[Gilles Caulier]

Hi all,

Since few days, i'm working to implement a new plugins interface, only
based on Qt5 API. No KF5, no KXMLGui, no desktop files, no share with other
applications.

Typically, the source of my analysis come from to backport the new Qt based
tool to play with GMIC filter.

https://github.com/c-koi/gmic-qt

I take a look in source code, and it's definitely complex and a waste of
time to duplicate this code in DK. Also, i remember the bad Veaceslav
experience with GMIC library, few years ago.

So, as you must know, we left kipi project and removed all relevant code in
digiKam about this KF5 interface that we write in the past due to lack of
support for other kipi host applications and about some several limitations
about in-deed use of kipi plugins outside of main album-view. Even if all
kipi tools have been backported in DK core as well, there is no plugins
interface anymore in DK.

But...

As you must already seen in this room, i'm a big fan on Marble application.
A pure Qt5, working everywhere without KDE and with good code ideas inside
where we can take inspirations.

Marble is mature and has plenty of plugins. Typically, the application have
a big core, but all tools are plugins. The plugins interface is too much
complicated for DK as well, but few good ideas... and this is what i do
since few days.

A plugins low level interface for DK is done on my computer. Plugins are
.so libraries, loaded at run time. Plugins are placed in the system
(/usr/libs/digikam/plugins) or in home directory, typically for development
or testing purposes (~/.local/share/digikam/plugins)

The plugins interface will be able to manage different types of tools :

- export tools (available everywhere : album-view, editor, LT, Showfoto).
- import tools (idem).
- image editor tools (for image editor and showfoto)
- BQM tools (for batch queue manager only).

For the moment, i only port one tool : SendByEmail. I also written an unit
test tools to scan all plugin from comment lin, and load specific one to
run it as a stand alone instance. All work as expected.

The next stage is to plug the tools on GUI (menu, toolbar), without to use
KXMLGui API. More tools will need also to port as well.

Advantages to use an extended interface with plugins loaded at runtime,
compared to the hard coded embedded way used currently are these ones :

- libdigikamcore which include all tools is heavy. Using shared libs
loadable in demand will require less memory and the application will be
more reactive.

- The plugins can be enable/disable on demand. This is very useful for the
export tools which because obsolete due to change in webservice API. The
plugins has a blacklisted list of tools.

- The users will be able to simplify the GUI with non wanted plugins.

- The new contributors who want to write new plugins will only needs to
know few API that we will point in API doc, and not all the digiKam core
API. Typically, i written DInfoInterface class in this way, which permit to
use the images and albums info with or without the database (in case of use
in digiKam or Showfoto).

Voilà, more details and progress will be posted here in few days, depending
of my advances in source codes.

Best

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