<div dir="ltr">Hi all,<div><br></div><div>Some news here about new plugins interface.</div><div><br></div><div>The main interface is mostly done, and can be used to port all webservice tools later.</div><div><br></div><div>The code is for the moment in a dedicated branch : </div><div><br></div><div><a href="https://cgit.kde.org/digikam.git/tree/?h=development/dplugins">https://cgit.kde.org/digikam.git/tree/?h=development/dplugins</a><br></div><div><br></div><div>The code is here :</div><div><br></div><div>The plugins interface : <a href="https://cgit.kde.org/digikam.git/tree/core/libs/dplugins?h=development/dplugins">https://cgit.kde.org/digikam.git/tree/core/libs/dplugins?h=development/dplugins</a></div><div><br></div><div>SendByMail tool ported : <a href="https://cgit.kde.org/digikam.git/tree/core/utilities/assistants/sendbymail?h=development/dplugins">https://cgit.kde.org/digikam.git/tree/core/utilities/assistants/sendbymail?h=development/dplugins</a></div><div><br></div><div>The unit test for the plugin loader : <a href="https://cgit.kde.org/digikam.git/tree/core/tests/dplugins?h=development/dplugins">https://cgit.kde.org/digikam.git/tree/core/tests/dplugins?h=development/dplugins</a></div><div><br></div><div>The TODO list :</div><div><br></div><div>- in Plugin Loader, write a method to merge the plugin actions to UI RC files. Plugins action are categorized to be placed at the right place in menu.</div><div>Actually, the tools menu entries are hard-coded in all UI RC files. The goal is to do the job automatically. We must don't use the KF5 XMLGUI API here, to be able to port the application  as pure Qt5 in the future.</div><div><br></div><div>A simple merge method can be written, similar than libkipi one :</div><div><br></div><div><a href="https://cgit.kde.org/libkipi.git/tree/src/plugin.cpp#n317">https://cgit.kde.org/libkipi.git/tree/src/plugin.cpp#n317</a></div><div><br></div><div>In fact we need what :</div><div><br></div><div>1/ Patch all UI RC to drop all hard coded menu action. For exemple this section :</div><div><br></div><div><a href="https://cgit.kde.org/digikam.git/tree/core/app/main/digikamui5.rc#n124">https://cgit.kde.org/digikam.git/tree/core/app/main/digikamui5.rc#n124</a></div><div><br></div><div>2/ Add a section delimiters in UI RC file using XML comments for ex, and at start-up, fill the section with all actions found by plugin loader.<br></div><div><br></div><div>3/ At first time to use digiKam, we use the system based UI RC file. We merge action in sections and write the UI RC file in local, in home directory.</div><div><br></div><div>4/ at next sessions, we always use the local UI RC file. This is how libkipi work in fact to plug tool at startup.</div><div><br></div><div>If you look in UI RC file the tool action are just one simple line to add. Nothing more. We don't need a complex API from KF5 to do the job. This permit also to base plugins to pure Qt5 classes only. It's safe for the future.</div><div><br></div><div>Voilà. that all for the moment.</div><div><br></div><div>Gilles Caulier</div></div><div class="gmail_extra"><br><div class="gmail_quote">2018-08-03 22:59 GMT+02:00 Gilles Caulier <span dir="ltr"><<a href="mailto:caulier.gilles@gmail.com" target="_blank">caulier.gilles@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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" target="_blank">https://github.com/c-koi/gmic-<wbr>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/<wbr>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><span class="HOEnZb"><font color="#888888"><div><br></div><div>Gilles Caulier</div></font></span></div>
</blockquote></div><br></div>