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.

4 Likes

Not a developer, but since it seems all the latest apis(that people are being confused by) were things I added, I was going to post it up but kept being distracted, sorry :frowning:

here is a list:

  • note there may be others added that weren’t mine
Document

createTransparencyMask : Creates a transparency mask node
createColorizeMask : Creates a colorize mask node

ColorizeMask

Ability to modify and generate colorize masks

TransparencyMask

Ability to modify transaprency masks and prevent them from crashing

TransformMask

toXML : Output TransformMask as XML string
fromXML : Set transform from XML string

CloneLayer

sourceNode : Show the original node CloneLayer is based on
setSourceNode : Set the node CloneLayer should be based on

Shape

== and != - Compare if the shape is the same shape
parentShape : Find the parent of the current shape
absoluteTransformation : The absolute transformation of a shape
including all grandparents

VectorLayer

shapeAtPosition : Gets shape at a certain point
shapesInRect : Returns all shapes within a rectangle
createGroupShape : Groups top level shapes into a GroupShape

Node

findChildNodes : finds all child nodes directly or recursively that
match the given criteria within a node. Search by name partially or
fully, by type or by color label.

Preset

toXML : dump all brush preset preferences
fromXML : change brush preset preferences

View

flakeToDocumentTransform
flakeToCanvasTransform
flakeToImageTransform

Window

dockers : get a list of dockers for the set window

Krita.instance().dockers() fixed to not crash if declared before
mainwindow is loaded.

PS I probably should add the api changes to the developer tools when I have time so people can see the new ones automated

3 Likes

What I am trying to say is that it would be nice to have a proper API section in the Krita Documentation. Where next to each object and method there is a tag saying the version the method was introduced or obsolete and other related information.

At this point it is a bit if a headache to figure out which method does what.

PluginDevTools makes life easier, but it is more about the availability of information in one place.

3 Likes

I agree it would be nice to have some kind of documentation for API changes between versions. I’m not sure what that should look like or how it should be generated, though.

In theory this is possible by using @since and @deprecated doc comments. Krita’s API documentation just doesn’t seem to use that anywhere currently.


I took a quick look for what I could add to the list of API changes in 5.2. I didn’t find much:

  • [Breaking] As a result of dependency updates, certain (Py)Qt functions such as QRect() that require integer arguments no longer automatically convert floats.
  • [New] FileLayer: scalingFilter() was added. setProperties was modified to take this new, optional argument.
  • [Changed] Document: setActiveNode(value) returns if value is false. Previously, passing a false value would cause a crash.
1 Like

I don’t mean in the Python API tools themselves, I meant in the online documentation that comes with them:

https://knowzero.github.io/Krita-PythonPluginDeveloperTools/plugindevtools/PluginDevTools/kritadoc.html

I added the ability to compare versions, and also to see changes between versions.

Select 5.2rc1, then compare it to 5.1.6 and click “Show New/Changes Only”

But as freyalupen mentioned, someone can add a @since, you don’t even need to compile Krita for that and can do that in the editor on the git kde invent website

1 Like

Btw the documentations does not have to be fancy.

It is just tedious to figure out what possible with API and what not. Everything just scattered around.

Regarding the particular methods or symbols versions. There do not have to be something fancy with icons and stuff. Just mentioning something in the docstring is already good enough.

Here are couple examples:


Isn’t that autocomplete?

It is just an illustration how depricated and new methods or arguments can be highlighted.

All the info is still comming from doc string.

If you want it to show up in the IDE, that would be autocomplete, so even if it is included in the documentation, it wouldn’t show up in the editor unless you have autocomplete going or manually inspect the objects

The point is not autocomplete :slight_smile:

The point is to indicate in a docstring which version the method was introduced or deprecated. The same goes for arguments.

Let’s take an example.

When I look at findChildNodes method on a Node class in a documentation. How do I know that this method does not work in Krita 4.8 or even 5.1?