A solution like that would be confusing, in my opinion: the colored border/frame (red in your example) looks like describing the content of the target layer.
Put a layer in this stack with a real colored frame, and it will be impossible to differentiate both.
Sounds like a good idea, how about such an icon for the layers:
how about:
An overlay?
(that one is from font awsome)
I definitely prefer an icon that is only displayed if the feature is used. I would not mess with the thumbnail. Also, we have a request in another thread to optionally hide thumbnails.
As for the icon’s design, I don’t have a strong opinion. The most important feature should be that the icon will show the selected color somehow.
Ah ok… What about placing the icon before the layer name?
I mean, unless we have a really good reason to deviate from the current design, we shouldn’t. The icons are located on the right. Implementing it in other way is needless complexity.
Yes but the placeholder in the colorize mask is triggering me 
Hi
To already had to work with icons in layers stack with the option “antialiasing on vector layers”, Krita’s internal implementation for icons already manage everything.
I’m not the best placed (maybe someone from the dev team @tiar or @dkazakov could give better advice) but it makes sense to me to try to continue to use the default implementation.
Starting to implement specifics behaviour to display an icon will complexify code, maintenance, future improvements implementation and is prone to bugs 
Grum999
What you are looking at is a snapshot of development. It won’t stay like this. I will remove this gap, and also need to do many other things before this is ready.
I am sry, because there are still specification for this feature missing or I don’t know about them, I keep thinking about it… let me make the specification as clear as I can so that I don’t keep bothering you:
As a User I want to color all pixel on any kind of layer in a color I selected, while keeping the opacity as is. ( akin to locking the transparency and paining over with a huge brush)
Did I miss something?
Yeah, that sounds about right.
However, you know, as long as we don’t forget about an important use case, I’m not too thrilled to keep a detailed specification like this 
I’m doing this after hours and enjoying a more “freestyle” approach. I will do what seems sensible to me, or if I’m out of ideas, I’ll come here for feedback.
Long before the change is accepted, there will be MR builds available that people will be able to test, and if it turns out that my intuition was wrong, and something works poorly in practice and people complain, I’ll just go back and change it 
I hope that is satisfactory.
I don’t have any visual update, but I’m inching forward. There’s no placeholder spot anymore, masks can’t have this feature enabled, etc. Still a lot of things remaining to figure out.
Well specification is needed, to prevent unnecessary changes. For example you build a feature and because you did not have any specification, you implement it in you way. But then it is not what should be implemented and you have to start again… or like when I throw so many suggestions at you. I maybe redirect your focus into the wrong direction, as the specification is not clear…
It also makes it easier to program that way as you do not have to think what to implement, but how. And there is no derailing.
Naturally, you’re right.
With what was discussed so far, I believe there’s no risk of developing something that is completely off mark.
- in the layer preferences dialog is a new option to activate this feature
I think the feature should be activated in a per-layer basis, not in the preferences dialog. The preferences might have default color setting though.
- an icon is added before the current icons of the current layer
That surely need an illustration. Before the layer thumbnail or before the layer
The questions that need answering:
That basically defines how we should implement this feature. My original proposal was to just add a hidden mask (with an ability to unpin it). It would behave as a normal mask all the time, so the answers to the questions would be obvious.
Bascially, we could also implement that as a “pin mask” feature. Basically, one can pin any mask to the layer, which would be put in the end of the masks list. The icon of the mask would be visible next to the layer. The “blue filter” icon would be visible next to the layer’s icon itself
Hi @dkazakov, you can see how the current UI is shaping up in this post. Since then I have fixed some things, for example there are no unexpected gaps and the effect can’t be added to masks/filters, etc.
I’m working only on the UI parts, i.e. the mechanics of turning it on/off, invoking the properties dialog, and so on. I plan to hook this up to your prototype, I don’t plan to do any implementation of the effect itself. Of course it will require some refinement after integrating, e.g. the blue filter layer should not be visible in the layer stack.
I haven’t pushed my code online yet, but if you’d like to look at the current WIP state, I can do that.
Hi @dkazakov (or anyone who knows), is this the latest available implementation of the filter?
I’m at a point where I think the next step should be integrating that code and trying to hook it up to the UI.
Hi, @YRH!
The GUI part looks nice, thank you! The link to my implementation is correct. It is just a filter that was supposed to be added to a layer as a filter mask.
You can start hooking it up like it is done in KisLayer::selectionMask() for selection masks. Just add a filter mask into the list of layer’s masks and see how it works.
After that, make a MR and we will discuss how to hide it from the GUI in a better way. The most obvious idea would be to modify the two methods:
KisModelIndexConverter::checkDummyType()KisModelIndexConverter::checkDummyMetaObjectType()The first one is used to hide already existing nodes, and the second one is used for the ones that are yet to be created (no object exists yet).
The problem of this approach is that this filter mask may be reordered with normal masks, which will cause confusion and bugs for the user. That is a part of the requirement question I wrote above:
- What happens if the layer has some masks or layer styles?
Anyway, we can postpone the question of hiding till after the initial hooking is done 
Great, thank you for the tips!
I think we need to somehow ensure this overlay coloring is applied last. It should color the layer as well as it’s stroke effects, for example.
We will improve it in the review.
Good news, I got Dmitry’s filter working in master, with just minimal code compatibility issues. Pretty remarkable given that these changes were created 4 years ago Nice.
I did skip one patch, but I think the same bug may have been fixed already in a slightly different way.
I haven’t tested it much yet, or attempted integrating with the rest of the UI, so yeah, basically just reporting in.
I have a bit of a rough time getting it to work.
I looked at KisLayer::selectionMask(), and I understand it’s a way to grab a specific mask that’s already there (e.g. the first FastColorOverlay in the stack), but I first need to add it to the node.
I was able to add the new mask through KisMaskManager, but it would be better if I could do it directly from KisLayer, where I have other functions related to this feature (such as enabling the layer coloring). But then I encountered other issues with that.
Anyway, it gets a bit too convoluted to explain here, so yeah, I’ll continue experimenting for a bit longer. I hope to get a bit farther before posting a MR.
