<div dir="ltr">Hi all, <div><br></div><div>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.</div><div><br></div><div>Typically, the source of my analysis come from to backport the new Qt based tool to play with GMIC filter.</div><div><br></div><div><a href="https://github.com/c-koi/gmic-qt">https://github.com/c-koi/gmic-qt</a><br></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>But...</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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)</div><div><br></div><div>The plugins interface will be able to manage different types of tools :</div><div><br></div><div>- export tools (available everywhere : album-view, editor, LT, Showfoto).</div><div>- import tools <span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">(idem)</span>.</div><div>- image editor tools (for image editor and showfoto)</div><div>- BQM tools (for batch queue manager only).</div><div><br></div><div>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.<br></div><div><br></div><div>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.</div><div><br></div><div>Advantages to use an extended interface with plugins loaded at runtime, compared to the hard coded embedded way used currently are these ones :</div><div><br></div><div>- libdigikamcore which include all tools is heavy. Using shared libs loadable in demand will require less memory and the application will be more reactive.</div><div><br></div><div>- 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.</div><div><br></div><div>- The users will be able to simplify the GUI with non wanted plugins.</div><div><br></div><div>- 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).</div><div><br></div><div>Voilà, more details and progress will be posted here in few days, depending of my advances in source codes.</div><div><br></div><div>Best</div><div><br></div><div>Gilles Caulier</div></div>