Installing a new plugin: I agree it has too many steps. When creating the plugin, there is an option to automatically enable it, too. It must be added to the Import Python plugin too (as a checkbox, I guess, and checked by default). And then there needs to be an instruction “please restart Krita to see the plugin in action”. That will make it clear for users what to do.
Plugins available by default were written to just showcase the possibilities in Python API, afaik. They can be changed or added etc., but I think all plugins there needs to be either GPL or CC0 (like some of the already available ones) to allow modifications and to allow distribution within Krita. And it would need some investigations, which plugins are the most useful, which are the most reliable etc.
It’s currently very hard for a new comer (I don’t imagine for a beginner) to understand how to create a plugin (it took me time to create the first one)
Have you used the Python Script Starter?
I was thinking of documenting a whole process of making a new plugin. Like a tutorial. It would use the script starter since that’s the easier way to get it all started, I think.
PyKrita API has a good base, but there’s too much thing that don’t work or that don’t work as expected
It would be good to make a list of things like that.
That is, I believe, a historical thing. Krita had macros there before and stuff. I agree that even if we get other Tools, it would be better to have Plugins as a separate menu entry. I also agree with having subcategories - it will be easier to find the specific plugin you look for.
I agree with 3.2, not sure about 3.1, maybe it should be in managing resources instead?
That won’t be that straight-forward because (1) there is no specific place with Krita’s plugins that would be managed by Krita; all of them are shared on different places like github, KDE Invent, only those that are included in Krita itself are on the list by default, and they don’t need downloading, (2) Krita by default has no connection to the internet (vide News widget on the Welcome screen, off by default), (3) allowing adding custom urls would be a bit of security risk for users, and if Krita shows those urls, it’s kind of like saying “sure, they are safe!”, while we cannot be sure about that.
It might not be that easy to do.
Ok, so my version of
TODO list
- Fix menu entries for plugins
- rename
ToolstoPlugins - figure out which categories we’ll need
- rename submenu entries for plugins from Scripts to those subcategories
Note: I didn’t check it but I guess it’s entirely possible that those things above can be achieved in scripts themselves; they select the location they are in after all.
- rename
- Add checkbox “enable plugin”, checked by default, to Import Python Plugin script
- Improve
Resources page→pluginssection - Resources — Krita Manual 5.2.0 documentation- add all the plugins in the development that are here on KA (ask the developer if it’s ready to be used (if not, don’t add it to the page) and if it’s considered finished (if yes, mention it, possibly))
- divide plugins into categories
- add one or two sentences of what the plugin actually does, since it’s not exactly obvious often…
- two links: one for the source code and stuff (ex.: link to the github main page for the project), and one to just download the .zip directly.
- Reconsider default set of plugins
- Possibly include more/prettier plugins by default in Krita.
Steps that every plugin developer should take to include their plugin into Krita:- publish the plugin in GPL, CC0 or similar, compatible license
- (all files needs to have license on top + information about the author, unless it’s CC0, there could be a LICENSE file as well)
- it needs to be put for review as a MR on KDE Invent: invent.kde.org by the developer (or possible maintainer) - it needs to be checked for security etc. before it can be added to Krita
- the developer (or the person who puts it for review) needs to pinky swear they will maintain it (for example fix important bugs)
- note that all improvements to the plugin will have to go through the same review process as well. The development of the plugin can still happen in the developer’s private repository and it can still be distributed and linked etc.
- Better manual how to create plugins.
For example this page: How to make a Krita Python plugin — Krita Manual 5.2.0 documentation could be summed up by “just use script starter”. It needs some planning. There are multiple pages inUser Manualpart: Python Scripting — Krita Manual 5.2.0 documentation and one more inContributors Manual -> Untranslatable pages: Python Developer Tools — Krita Manual 5.2.0 documentation - it needs to be integrated and thought through. Maybe the User Manual should only say how to import them, and Contributors Manual how to write them? Or all should be in User Manual? Or some parts in Reference Manual? - Make a list of improvements and shortcomings of Python API.
I would like to get @halla 's approval first but it looks like a good candidate for a Phabricator task.