API improvements feedback and expectations

[yetanotherpainter]

I have been developing Python Plugins for a while now, and I have collected some observations that might be helpful for Krita developers. Here are those.

1. Docker Widget
Resizing the docker is real pain (I spend 10-20 seconds every time to hit that one single pixel to resize the docker).

2. Interpreter

Some sort of a way to reload your plugin to refresh the symbols. Save time from constant reloading of Krita every time you change something in the code. Same way Jupiter Lab does with its notebooks.

Example how it works now. Create a script with name main.py. Create a script with a name func.py, add function hello to the func.py. Import it in the main.py. Load the main.py in the scripter. Change the hello function - the changes are not reflated in the scripter.

3. API coverage and versioning

In general, Krita lacks proper API documentation. The developer spends a lot of time trying to figure out what is possible and where to get the description of the method node.childNodes (make sure it is true though) does not work on Krita 4.8 is to run the code. As a solution to this point it would be nice to have in the docstring small comment. Something like this: introduces since 5.2.1

As a perfect solution it would be good to move the documentation to the engine that Godot Project uses: Groups — Godot Engine (stable) documentation in English

This way all the docs will be related to particular version and it will be clear for a user what version associated with the API.

Catching the changes on the forum is a bit unstable for my opinion. There should be only one place to watch for this changes (apart from the changelog.md file in the repository).

With the tool from @KnowZero it became better. Still, I think it is a good idea to reflect the appearance of the method in a new version in the doc string.

4. Changes of the API functionality

This on is similar to documenting. But more interactive.

It would be nice to have a deprecation warning when the method is going to be obsolete. So plugin developers will know that they have to adjust their source code before next Krita version to guarantee high quality of their plugins to the users.

Here the discussion that already happening around this idea:

Krita API changelog, so the plugin developers can prepare their plugins for new releases

Recently I stumbled upon this reply: Turns out, the code snipped was specific for Krita 5.2+ version. I was wondering if the developers are going to somehow clearly communicate API changes? It would be good for developers to know what API calls are added, which ones were changed and which ones were removed.

5. API changelog as part of a release changelog

I was thinking that It would be helpful if the API changes were included into a press release when the new Krita version is out. Or at least there should be some sort of a file in the repository where everybody knows if he needs to know what changed, there only one place to look.

6. Hacking

There are many examples on KA when something is being achieved by getting instance of particular button and calling click() method (example: Is it possible to programmatically create compositions?). From my point of view for cases like this Krita API should have a function or object to do this operation. Or some other smarter way to “get” the responsible object. Connect to a signal and/or register handler. I do not think it is a good idea to develop plugins that are relying on particular widget name or a structure.

7. Docker/Plugin in the code base

Some of the functionality in the Krita itself comes as plugins that are just part of the software. I think for this case Krita Team could write a guideline (for contributors) on how the plugin should expose the API for functionality that it provides. Then while compiling API, plugins can also be included. Which will benefit scripting a lot.

8. Sequential nature

For the actions that we are getting from Application.actions() list. It would be nice if the back end could guarantee the order of their execution. Meaning that the actions that are called from scripter could be triggered in “sequential” mode. Not in asynchronous as it happens right now.

Dynamic Libraries as plugins

The idea is to enable the ability to add plugins as DLL files (I guess LMMS does that). That way plugin developers can do their plugins via C++ without need of shipping own version of Krita and the plugins will be optimized too.

In general. Considering the lack of resources for core team I think it is a good idea to make and effort towards making Krita easily expandable with plugins. So the community and individual developers

would make things that Krita is lacking. BoxCutter is a good example in the Blender world.

9. Scripter as a Docker

This might be more related to the plugin “Krita Plugin Developer Tools”. Though, It would be nice to have an option so that the Scripter window opens as a docker.

10. Runtime engine for VSCode

It was discussed on the forum before, that it is not possible to just locate “site-packages” directory to expose the API to the IDE that is used to write the plugin. However, maybe it is possible to add some sort of a service that runs on localhost so VSCode can connect to it the same as with connecting to WSL or docker containers. Something like a remote environment. Where the Krita package will be installed and the developer will be able to get all from the type checking and all of that.

11. Enrich API with events

Expand Notifier to be able to connect to event that are happening in the application. Or maybe even let the developer to connect to signals from other tools like MoveTool or others. Examples

• Tool selected
• Selecation created
• New Layer created
• New foreground color is set
• Layer moved
• Etc.
• The full list of event can be gathered from the community.

In general there are a lot of things that can be useful for the developer to make their plugin to react to. Adding slots to a lot of events in the Krita and giving the ability to connect to them could be a good advantage.

Here is the discussion of such a case:

Select something = automatically enable MOVE mode

One of the oddest things in Krita is the necessity to manually switch to “Move” mode after select something. Assume I select a rectangle area. Why do I have to explicitely enable “move” mode to move this rectangle? Even worse: When I want (after move operation) to move another rectangle area I have to click again the “select rectangle” tool. Lots of unnecessary moves! Other image editors enable silently move mode when selecting something. I guess this silent implicite “move mode” switch can…

Having the selectionCreated event might solve this problem with couple of line of script.

[YRH]

That’s a great list of ideas, everything here sounds sensible and useful to me.

I think it’s very unlikely that the core team will act on anything here unless it somehow already coincides with what they are working on. My suggestion would be that you start working on this yourself, starting with whatever looks the easiest or most useful. In my experience, that’s the best way to make things happen.

Even if it takes you half a year to get just one thing done, it may still be faster than waiting for someone else to pick it up. If you are missing any skills now, you can learn on the job.

[yetanotherpainter]

I agree. In any case I am making my point so that maybe other people will catch up on the ideas. Or at least it will be in some TODO list anyways.

[freyalupen]

@yetanotherpainter

As a perfect solution it would be good to move the documentation to the engine that Godot Project uses: Groups — Godot Engine (stable) documentation in English

This seems it would be essentially like moving the scripting documentation into Krita’s manual. Which, maybe combining the API docs, the Scripting School tutorials, and the Python Scripting section in the manual all into one place isn’t a bad idea.

(By the way, the equivalent page of Godot’s docs to Krita’s Python API docs is this one, the class list. The one linked above is instead a scripting tutorial, akin to Krita’s Scripting School.)

Having a good foundation for documentation seems to me a good place to start, so that any additions to the API can be properly documented.

---

@yetanotherpainter

I do not think it is a good idea to develop plugins that are relying on particular widget name or a structure.

Of course not, that’s a hack. There are plenty of things that could potentially be exposed to the API properly, but it seems like it would take some planning to figure out the what and how of it.

---

At any rate, it’s quite a long list. You’ll just have to pick something and take a shot at it, then you can ask for advice from the devs about whatever you’re working on. Once someone starts working on something, it makes it easier for others to join in (I guess).