Registered Member
|
Hi everyone!
I have few questions: 1) Where can I find a Krita roadmap and things that already implemented? I have found several sites, but they weak about info and out-of-date. 2) In source code I have seen a "plugin" catalog. How to install plugins into Krita? Thanks! :) |
KDE Developer
|
Ah, good questions! Basically, there's nothing very up-to-date about our roadmap. We tend to get surprised ourselves! For 2.6, my focus is on suitability for integration into film work, like textures, stills, mattes and other assets.
As for plugins, they need to be written in C++. There aren't third-party plugins available as of now, but anyone who is working on one, please do contact us, either here on on #krita or kimageshop@kde.org to discuss the best way of making those available. Pretty much all krita's functionality is a plugin, so there's plenty flexibility there! |
Registered Member
|
I understand it correctly, that Krita is monolithic program? Just I did not find any plugin manager or something else for dynamic load/unload plugins
|
Registered Member
|
That's not correct, Krita is not a monolithic program: every brush engine, every filter, every tool, is a plugin. You can even add extra colorspaces on top of the basic ones (located in calligra/libs/pigment) through plugins.
But no, we don't have a plugin manager, they are plugins but must be compiled along with Krita, it's not something you can load at run-time through a plugin manager or some similar feature. Edit: you may ask then, "are they really plugins if you must compile Krita with them?", yes, they are, because if you remove them, the program still works. You can add or remove paintops, filters, and the program still operates. They're not part of the core application, just like you'd expect from a plugin. |
Registered Member
|
Thanks for answers! This thing, that plugins compiles with Krita confused me a bit. :)
|
KDE Developer
|
Plugins are loaded at runtime. They are located with the KDE plugin system which means that every plugin provides a .desktop file. So it just needs to be in the right directory and ksycoca has to know it.
Krita does load all the plugins at startup and can't be removed during runtime. The reason to do this is that pretty much everything in Krita is a plugin (even the application itself in some way), so if the plugins aren't loaded you can't do anything at all. Plugins integrate so deeply into the application that they can't be easily removed e.g. the current image depends on plugins like the RGB colorspace which is just a plugin in Krita. Krita doesn't install headers for plugins, so if you want to develop plugins you can't do that with the Krita package from your package manager. Instead you build Krita yourself. It's usually much easier to build the plugins as part of the Krita source tree, so pretty much everybody does that. |
KDE Developer
|
there has been discussion about a runtime plugin manager at one point -- kde provides the tools for that. But I've never had a user ask for that: nobody has ever told me that they really would like to remove the transform tool from the toolbar or a particular colorspace from the list of colorspaces. That said, we've started at various points in time extra repositories for developing plugins and a website for cataloging them. But because these plugins aren't in krita's source repo, and because we change the api all the time, those plugins tend to get broken. Here's the git repo: https://projects.kde.org/projects/calli ... extensions
|
Registered users: abc72656, Bing [Bot], daret, Google [Bot], lockheed, Sogou [Bot], Yahoo [Bot]