talking about new digiKam plugins architecture...
Locked
talking about new digiKam plugins architecture...
 
|
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 : I this branch, i created some classes abou tthe new plugin architecture. all are located here : 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 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 ; 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 : 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@localhost dplugins]$ pwd
/mnt/devel/GIT/6.x/build/core/tests/dplugins [gilles@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@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@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@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 : 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 |
«
Return to digikam-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |