The GIMP has a concept called "parasites" in it's scripting API's. Parasites are simple key / value pairs you can attach to many (if not all?) objects accessible via the different scripting API's. This allows for a plugin author to get and set state data on e.g. global, layers, colors, transforms etc. throughout the API. Parasites are then stored and re-loaded with each document (.kra file). So a plugin can load and save data/state between sessions. I've contributed COA Tools support to this plugin https://github.com/GDquest/GDquest-art-tools and thus noticed that the project uses layer names for a similar way to store data/state/meta-data between sessions. I think it's about time to air the idea and to add some kind of key/value system that can follow a documents life-cycle, accessible from the scripting API - before we end up contaminating e.g. Layer names etc. (On a side note I'm also going to suggest adding user facing tag support to layers - giving plugins the opportunity to act on user specified tags)
Is this request coming from a specific thing you are trying to script with Krita, or are these just some ideas about high level coding architecture? In other words, is there something you are trying to code, but can't because of Krita's Python API? In general, the Python API is pretty new to Krita still and we are interested in seeing what people are actually trying to do with it -- but cannot because of the limited API. There are quite a few things that don't have any API at all right now. We are slowly adding stuff as people are finding uses for it.
It's a thing I've used a lot in The GIMP - and are missing in Krita's API. I'm of the understanding that many GIMP plugin authors also use parasites to store state among other things - so I think it will be useful to many other future plugin authors than just me. So to answer your question: It's a specific thing I'm missing :) It only becomes 'architectural' because this concept (parasites) touches, or could touch, many object types. I'm not enough into the codebase to know how big of a change it would be to give all/many/dominant objects this feature.
... and don't let the word "parasites" scare you off - it's basically just the ability to store key/value data globally and on prominent object types (e.g. layers, colors, brushes, patterns)
It would be an enormous change.
Ouch. So no base objects to implement this on?
No.
Git commit 8da59a65e15a5c61440c50937038e4dcd9b86ee2 by Halla Rempt. Committed on 02/02/2021 at 15:39. Pushed by rempt into branch 'master'. Add API to the Document class to handle annotations Annotations are blobs that are stored with the image. We use this for exif and icc data (except not really), and since 2008 we were intending to make it possible to store generic data with the image using KisAnnotation. M +55 -0 libs/libkis/Document.cpp M +33 -0 libs/libkis/Document.h M +45 -0 libs/libkis/tests/TestDocument.cpp M +1 -0 libs/libkis/tests/TestDocument.h M +5 -1 plugins/extensions/pykrita/sip/krita/Document.sip https://invent.kde.org/graphics/krita/commit/8da59a65e15a5c61440c50937038e4dcd9b86ee2
Okay, this is the best I can do: I implemented the KisAnnotation idea I first started working on in 2008. You can now associated qbytearray blobs with an image, and those blobs have a type and a description and are saved with .kra files and restored. What people put in the blobs is up to them...
Thank you!