talking about new digiKam plugins architecture...

Gilles Caulier caulier.gilles at gmail.com
Mon Dec 31 14:33:08 GMT 2018


Hi all,

First happy new year 2019 if it's not done by another mail...

I would to start a thread about the new plugins architecture that i started
to write, and explain the missing code to implement, in goal to have a
first version suitable in production.

1/ Where is the code

There is a "dplugins" git branch maintained and sync with master :

https://cgit.kde.org/digikam.git/tree/?h=development/dplugins

I this branch, i created some classes abou tthe new plugin architecture.
all are located here :

https://cgit.kde.org/digikam.git/tree/core/libs/dplugins?h=development/dplugins

Code is compiled in digikamcore shared library. So it's usable in DK and
also in Showfoto.

- dplugin.cpp is the abstract definition of a pure Qt plugin for digiKam. A
real plugin must be re-implemented from this class.
It include a lots of properties as version, description, icon, etc...

- dpluginaction.cpp is a container describing a plugin action runnable from
GUI to plug in menu (or in another place, as it's based on QAction). It
include all action properties. A plugin can have more than one actions
defined.

- dpluginauthor.cpp is a simple container with all plugin author
properties. A plugin can have more than one author of course.

- dpluginloader.cpp is the famous part dedicated to manage plugin instances
in memory. This manager is able to parse the plugin shared libraries
discovered in the system and load file in memory.
Currently the manager is able to load the files at startup, following a
black and white list of tools and provide a list of actions classed by
categories.
The manager provide also the XML section of the KDEXMLGUI section provided
by the plugin. In XML code is generated automatically by the implementation
of plugin, depending of properties set in code. There is no extra and
external definition of XML in separated file as with KIPI. In fact we don't
change these properties in time, and this kind of management is enough.

2/ Plugin files installed on the system

A plugin will only generate one .so file, and that all. It can be installed
in core system (/usr/... under Linux) or in home directory
(~/.local/share... under Linux).

3/ The demonstrator : SendByMail

In the dplugins git branch, there is only one tool ported as a new plugin :
SendByMail

https://cgit.kde.org/digikam.git/tree/core/utilities/assistants/sendbymail/sendbymailplugin.h?h=development/dplugins

This is a demonstrator. The tool still also compiled in DK core for the
moment, and of course later, when all plugin management code will be
completed, the core version tool must be removed in favor of plugin.

In point of view of CMake, we have just a line to add for each tool to port
as plugin ;

https://cgit.kde.org/digikam.git/tree/core/utilities/assistants/sendbymail/CMakeLists.txt?h=development/dplugins#n46

As you can see, making a plugin from the current tool implementations is
fast and easy.

4/ The demonstrator : loadandrun test tool.

There is a CLI tool to check if dplugin loader API work as expected :

https://cgit.kde.org/digikam.git/tree/core/tests/dplugins?h=development/dplugins

This test tool is able :

- to list plugin .so files available.
- to list plugin properties : descriptions, authors, action, name, version,
etc...
- to load and run a plugin action.
[gilles at localhost dplugins]$ pwd
/mnt/devel/GIT/6.x/build/core/tests/dplugins
[gilles at localhost dplugins]$ ll
total 668
drwxr-xr-x 4 gilles gilles   4096 déc.  31 13:37 CMakeFiles/
-rw-r--r-- 1 gilles gilles    992 déc.  31 13:37 cmake_install.cmake
-rw-r--r-- 1 gilles gilles    295 déc.  31 13:37 CTestTestfile.cmake
-rwxr-xr-x 1 gilles gilles 650424 déc.  31 13:48 loadandrun*
-rw-r--r-- 1 gilles gilles     93 déc.  31 13:38 loadandrun_automoc.cpp
-rw-r--r-- 1 gilles gilles   9400 déc.  31 13:37 Makefile
drwxr-xr-x 2 gilles gilles   4096 déc.  31 13:59 plugins/
[gilles at localhost dplugins]$ ls -al ./plugins
total 3220
drwxr-xr-x 2 gilles gilles    4096 déc.  31 13:59 ./
drwxr-xr-x 4 gilles gilles    4096 déc.  31 13:59 ../
-rwxr-xr-x 1 gilles gilles 3286888 déc.  31 13:47 SendByMailPlugin.so*
[gilles at localhost dplugins]$ ./loadandrun --list
digikam.general: Starting to load external tools.
digikam.general: Parsing plugins from
"/home/gilles/.local/share/loadandrun/plugins"
digikam.general: Parsing plugins from
"/mnt/devel/GIT/6.x/build/core/tests/dplugins/plugins"
digikam.general: Plugins found: ("SendByMailPlugin.so")
digikam.general: Plugin of type Digikam::DPlugin loaded from
"/mnt/devel/GIT/6.x/build/core/tests/dplugins/plugins/SendByMailPlugin.so"
digikam.general: void Digikam::DPluginLoader::Private::loadPlugins() Time
elapsed: 3 ms
--------------------------------------------
Id     : "SendByMail"
Name   : "Send by Email"
Version: "1.0"
Desc   : "A Tool to Send Items by Email."
Authors: "Gilles Caulier <caulier dot gilles at gmail dot com> (C)
2004-2018 [Developer] ; "
Actions: "sendbymail: \"Send by Mail...\" - GenericToolCat ; "
[gilles at localhost dplugins]$

>From the example list before, i created myself the plugins sub-dir where is
copied the send by mail .so file compiled from another build directory. I
reality, the plugin .so files are installed on the system and plugins
loader is able to detect files at startup.

Now to run the plugin it's very simple :

https://www.flickr.com/photos/digikam/46541494781

5/ What's missing to do.

As you can see, the basis is here, but nothing is changed internally to
digiKam implementation. It miss :

a/ to load plugin at startup
b/ to plug tools in menus.
c/ to configure tools to load or to ignore at startup, through the setup
dialog.

For a/, it's simple as loadandrun tool demo as already the code.

For b/, it's more complex. We need to write a pure Qt code (NO KDE API
HERE) to :

1/ cleanup the plugin entries in XMLGUI file.
2/ repopulate the entries in XMLGUI files accordingly with plugins .so
files detected, and withe/black listed plugins done in setup dialog.
3/ load the merged XMLGUI file in application. This touch digiKam album
gui, image editor, lighttable, and showfoto.

The stage 2/ is the more complex and no code have been written about yet. I
tried to use some older code from libkipi, which has this kind of mechanism
(and more as we can load and unload plugins in live), but code is puzzled
with KDE API everywhere and cannot be backported as well...

Voilà for the review. I'm waiting questions and feedback.

Best

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


More information about the Digikam-devel mailing list