How to develop and deploy plugins?

[Boudewijn Rempt]

yn Thu, 30 Mar 2017, Sebastian Wahl wrote:

> Hello Krita devs,

Hi Sebastian!

> 
> I have been looking into how to get Krita to load and save FLIF
> images. Since I had already made a Qt plugin I hoped Krita would pick
> it up automatically, but no luck there.
> 
> So I located the plugins and I would just copy the BMP plugin and
> change the MIME and extensions to FLIF's, but I can't see how to
> compile it outside the Krita codebase. (So for now I just recompiled
> Krita and patching the lines into the existing plugin, works great.)
> I did find some old documentation for Krita 1.6 which links to a SVN
> repository which doesn't exists anymore.

If probably would be enough to add the flif mimetype to the bmp plugin,
the bmp plugis is by now quite deceptively named: it's a basic let's-
reuse-qimageio plugin. I also started a similar plugin, using oiio. The
problem is... (let me transpose two of your paragraphs)

> A note on the image formats plugins, I think it is a bad idea to
> hardcode the formats support into the plugin meta-data. 

Exactly this... I would love to refactor this, but it's going to be
a bit of work. We already went from .desktop files to json files
when we ported from qt4 to qt5, but it's definitely not dynamic,
and that sucks.

> You could get
> support for lots of formats easily by picking up other image loaders,
> but since they are often also plugin based, you can't determine this
> at compile time without risking plugins missing at runtime. (It does
> require some sort of priority system in case of multiple plugins
> supporting the same format, but that is also the case if third-party
> plugins are allowed.)

The metadata system actually already had a priority system, but that never
really worked out. Like I said, it would be very good to refactor this 
properly. The way it current is, is just how it has grown from the original
KOffice roots in in 2000 or so.

(There's a further problem on Linux, though, where file format associations
are always done using metadata, namely the .desktop files, instead of
format introspection.)

> 
> So what is the current policy on third-party plugins? How should I get
> the needed headers to create a dev package? Or do you want all plugins
> to be pushed upstream?

Right now, we don't have external plugin support. That used to be present
in the 1.x days, but back then, krita wasn't popular enough so nobody
was making plugins. Not having a public api also made it possible to do some
sweeping refactoring, and as noted above, we might even have to refactor
the import/export api again.

> I think FLIF support in Krita would be great, but I regard relying on
> my Qt plugin as more as a quick and dirty solution rather than a long
> term solution. (No 16-bit, encode settings, etc.) My usage of Krita
> right now just isn't big enough currently to warrant spending the
> work.

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.

Cheers,

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