How to develop and deploy plugins?

[Boudewijn Rempt]

On Wed, 5 Apr 2017, Sebastian Wahl wrote:

> > The metadata system actually already had a priority system, but that never
> > really worked out.
> 
> How did it fail? I don't think such a piority system is trivial to
> design well, so any experiences would be useful.

Basically, we never had plugins that made use of it, so the code bitrotted.
It was never really tested.

> 
> > I think the best plan would be to start with a simple refactoring that allows
> > plugins to add wildcards to their static metadata: that automatically
> > means a lower priority. Then we can add a simple getter that gets all the
> > actual mimetypes from the plugin, and the plugin can get it from its own
> > resources. That wouldn't be a lot of work, and would make Krita use
> > your plugin if it's present.
> 
> While that would be great, but I'm not sure if that is the best way to do it.
> If we just want to lower the priority of additional formats, we don't
> need the wildcard. We could just compare the static metadata to what
> the plugin returns, and use a lower priority for those not hardcoded
> into the plugin. High and low priority is easily implemented by using
> set operations, instead of having to query for the wildcard, remove
> it, and then compare it.
> If we want to be able to expand to a more detailed priority system
> later I think we should put a little more thought into it so that we
> move in the right direction.
> 
> Since this would mean support for more than just FLIF I wouldn't mind
> putting in a bit work to make it happen, if nobody which is already
> into the source is interested in doing it. I have a few Qt plugins for
> custom formats and propetary formats (which I can't distribute), so
> being able to load them without having to convert them would be nice.
> Some pointers to which classes are relevant to loading/saving would be
> appreciated though.

Okay -- here are the main parts that make things work:

* KisImportExportFilter: base class for all import/export filters. This
probable needs to be extended to provide a way to get dynamic mimetypes
supported by the filter.

* KisImportExportManager::filterForMimeType: this queries, through
KoJsonTrader, all plugins of the Krita/FileFilter type. Right now,
it checks which import/export mimetypes are registered in the json
plugin metadata. It should also check which mimetypes are supported
dynamically. That means that on each query, we need to instantiate
the plugin, which means we probably are going to need some kind of
cache.

* plugins/impex/bmp: this probably needs to be renamed, and then
extended to query Qt which qimageio filters are installed, and
use that to return the dynamic set of mimetypes.

The priority is set in the "X-KDE-Weight": "1", field in the json
file that creates the plugin metadata. KoJsonTrader used to check
that field, and only return the top one. 

-- 
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org