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.
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
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
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.
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 ?
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
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
Concerning comments on layers, sure this will allows to write some plugins as workaround.
But:
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 )
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
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
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.
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
@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
)