new plugins interface for 6.0.0

[Gilles Caulier]

Hi all,

Some news here about new plugins interface.

The main interface is mostly done, and can be used to port all webservice
tools later.

The code is for the moment in a dedicated branch :

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

The code is here :

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

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

The unit test for the plugin loader :
https://cgit.kde.org/digikam.git/tree/core/tests/dplugins?h=development/dplugins

The TODO list :

- 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.
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.

A simple merge method can be written, similar than libkipi one :

https://cgit.kde.org/libkipi.git/tree/src/plugin.cpp#n317

In fact we need what :

1/ Patch all UI RC to drop all hard coded menu action. For exemple this
section :

https://cgit.kde.org/digikam.git/tree/core/app/main/digikamui5.rc#n124

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.

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.

4/ at next sessions, we always use the local UI RC file. This is how
libkipi work in fact to plug tool at startup.

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.

Voilà. that all for the moment.

Gilles Caulier

2018-08-03 22:59 GMT+02:00 Gilles Caulier <caulier.gilles at gmail.com>:

> 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/20180812/ea9ab6c6/attachment.html>