Layer comments

These are more suitable and descriptive that the circle ones. We might want to fine tune and tweak them a bit, but it can be done when we actually implement it.

I had initially thought about clicking and viewing the comments, hence I placed the icons with other properties. In addition to this there can also be a menu entry in Layer menu - Layer > Show comments which will show hide these icons on the layer. So that users can turn off seeing comments icon and make it less distracting when not required. It will be preferable to save the state of the menu with the document. So that when sending files I will enable the comments to show and the user receiving the file can see them hen opening the file. After checking the comments he can switch off the visibility and do his work.

On another note a disadvantage of keeping the icons on the left side like in your mock is that it will be too close to the layer type icon which itself is small and this would lead to slight clutter near the name of the layer, it also pushes the layer names a bit which might be an issue when there are nested layers and the layer name gets truncated further.

Yes I like that too, But your comment icons seems more apt to me.

I thought about keeping the group to green and layer/mask to orange but these were arbitrary colours I came up with they can be something else which go well with the various themes of Krita. We can leave the colours aside as they are not necessary once we use your comment icons.

Yes that’s a good idea.

Like “pinned to timeline” option

Yes, I wasn’t completely satisfied by my solution :slight_smile:

I’ll take these remarks to update feature request and provide an update with icons tonight.


Just a thought I think masks and filters can be also added to the list. Some time I may add a more than one filter and might want to note about it.

Concerning mask, I was considering that as a mask layer is applied to a layer, there’s no real need to implement it; I was more focused to set comment on parent layer in this case.

For filter layer yes, I understand.
I already asked myself about this, and mostly, the reason why I excluded them is just because the properties dialog box for a filter layer is not a default properties dialog box like for paint or group layer.
Dialog box match filter properties dialog box.

note: writting this, I realize that for file layer, the same problem occurs…

If we want to add comments to filter layer, I think in this case we need to implement a dedicated dialog box to edit comments, and then add new context menu entry to access to this dialog box.

Doing this will also allow to set comment on any layer type, maybe it’s simpler to implement :thinking:

On my side it’s not a problem, I can write specification in this way.
But before doing it, as it take time and as it start to impact heavily interface, maybe @halla’s opinion could be a good thing before :slight_smile:


I somehow would expect a file layer, as it’s an external resource, to show the comment of the actual file. You know, the one that can be set in the document informations. But of course it also makes sense to comment it in layer context.

It start to become complex :slight_smile:

What if the source file is not a kra file? (jpeg or png for example)

And in case of kra file as source file, many possibilities…
If kra file have information, we can initialise layer’s comment with information from kra file.
But is it really expected by user ?
What if kra source file information is modified later?

My point of view is more to not have comment by default, and let user fill it manually when needed.

But for a file layer, if source file is a kra file, maybe a button in comment editor to automatically fill comment with source file information ? :thinking:


Not entirely same but in 5.0 alpha you can see annotation in image properties. @halla told me it is related to this. So you can take a look at it. Maybe it will help in saving the notes in the document.

Annotations are basically binary blobs with a unique name that can be saved and loaded in .kra files. I recently finished a todo from 2005 about implementing them and exposing them to the Python API. You could encode the layer notes in whatever way you want, from plain text to .doc or rtf… and then serialize to a buffer and put the bytearray in a .kra file. It’s the easiest way of extending the .kra format with specific information.

That’s a very interesting thing for plugins :star_struck:
Many thanks for this new functionality!
I already asked myself about how to save data related to a krita file, without corrupting kra file but also to ensure that data won’t be lost in an external data file…

This is a really good thing :slight_smile:

Concerning comments on layers, sure this will allows to write some plugins as workaround.


  • Plugin doesn’t allow to tweak layer docker; so need to implement a specific docker, with layer tree, just to have an overview of layer on which a comment has been made; not ideal but better than nothing…
  • User need to install a plugin, and potentially add a new docker (on my side, less docker I have in my UI, better I feel :slight_smile: )
  • Implementation(s) won’t be standardized; what if, if user store comments in Krita file through a plugin, and for some reason plugin is not compatible anymore…?
    (If for some any reasons plugin developer is not able anymore to maintain plugin…)

So I think on my side I’ll start for a plugin because I want to play with this new API methods :slight_smile:
But I consider it just as a workaround and continue to think that native comments implementation -like the one described at the beginning- would be a better solution

Anyway, thanks for the suggestion and the interest that was brought to this idea, hoping who knows, to see it one day in Krita :slight_smile:


related to layer annotations:

in Notifier Class Reference there is void imageSaved(const &filename), but in most of cases it would be more useful to have signal before save has happened.

aboutToSave(document) signal could be used in python plugins to save custom information to layers.


I wouldn’t hook that into the saving action: just make sure the annotation to the image is up to date, and it’ll always be saved.

Keeping annotation up to date, is a bit problematic in my case.

Annotation contains a a embedded document similar to ShaderToy JSON, and it would be overkill to serialize whole embedded document when user moves slider that changes value of any uniform in shader.

It would be much better to serialize embedded document, only when save is about to happen.


I agree, an aboutToSave(document) signal could be interesting :slight_smile:

@halla I started to write a plugin to take notes, using annotations.
Annotations are really cool for this, but currently notes will be global to document without any possibilities to link it to a layer, because Node class doesn’t provide any Uuid.

Is it possible to extend Node class to publish Uuid?
Looking kis_base_node the uuid() method exist so I think it should be possible to get it in Node class.
It seems this is the same Uuid that is stored in kra file and I imagine this uuid is unique to a layer and never change (only case: a cut/paste layer, what happens?)

After I didn’t look deeper about it and I don’t if it really make sense to publish it in API.
And I know that, even with the uuid there’ll be other thing that won’t be possible to manage properly with plugin (like merge) but having a unique identifier available in API will in anyway be really useful :slight_smile:

Do I create a new feature request for this?


Yes, though you might have to wait for Krita 5 before you can use it.

1 Like

No problem to wait for Krita 5 :slight_smile:


Oh change is already committed in master :star_struck:

(And thanks for the extra nodeByUniqueID()method! :grimacing:)