We can name them Assistants later in the UI, which makes sense. Every Krita user who knows Masks knows how they behave in the layers docker, so I think it’s why we call them masks in this discussion, because everyone then can imagine how they get integrated into the layer stack.
We can just name them “Local Assistants”, it works with “Local Selection”, no need to use either “Mask” or “Layer”. I think “Layer” would be just as confusing as “Mask” here. Unfortunately, the one appropriate term - “Node” - would not be understandable to artists either 
8 Likes
But this way you split the assistants away from the objects they belong to.
Especially looking at your example with the city, and all the different objects in a city, I find it helpful to have the assistants at the layers of their belonging objects.
At least with my workflow/level stack this would be very practical and would probably be the solution that makes most sense¹, because every object has its own group in the level stack, every single house, car, character, has its group which in turn is organized in supergroups for houses, cars, characters. So I find it convenient that each assistant can be found with its object.
Michelist
¹) This does not mean that other concepts could be more advantageous for other ways of working.
Add/Off-Topic/TL,DR: Who knows, maybe this compulsion to order is due to having learned technical drawing in mechanical engineering, there you have to work this way to not lose track of thousands of parts and sink into chaos. And it would have been the same in my later work as a surveyor, when we mapped the supply networks of entire cities. Without strict mappings, this work would not be efficient.
I know that naming is secondary here, and I don’t really have any strong need for the names to be changed. But, the problem is that the wrong name was selected for those “modifier layers/modifiers”. A mask has a strict definition both on traditional and digital art. It is like a stencil, something used to protect some areas when painting or printing (in photography also) traditionally. Digitally is a grayscale image used to hide/show some specific areas of another image. So, I would say the transparency mask is just a mask. If you think of it as 100% opacity effect * a mask, then I think you are overthinking it. The filter mask is not simply a mask, it is a filtered version of the layer produced by applying the filter + a mask that establishes which areas of that filtered version should be painted over the parent layer. The fact that you can paint on it is not sufficient to call it a mask, otherwise you could also call the filter layer a mask. The other mask types are very confusing regarding their names.
4 Likes
I’m a little torn here, because I think ”assistant mask”, i.e. assistants limited to specific layers, is something a lot of people would find useful. Personally, I don’t think I’d benefit from them. I mainly use layers to test things out before committing to a change in the painting, and tend to merge everything down to only a few, or even just one layer. There’s no fixed layer structure that relates to the content of my paintings, and so assistants tied to layers don’t seem a great fit for me.
I chose tree in tool options because it seems the most reasonable here, although an assistant docker is not much different from my POV. Being able to group assistants would be good.
None of the options really scratch my itch, though. I don’t like going to dockers much to begin with -they’re way out there on the edge of the display! I’d prefer some kind of quick menu that pops up at the cursor when summoned . Preferably there should be arrows to indict age the direction each assistant is in when mouseovered in whatever menu pops up.
2 Likes
You could just have several assistant layers attached to your main layer, that allows for grouping assistants and for example disabling them at once, changing their colors, locking them (I’m not sure yet what controls will be there but I hope to get the most useful ones). So you might have some benefits too.
1 Like
That’s true, but what the ”main layer” is changes… it sounds like I’d need to have a top level group with everything in it, and add assistants to that. I’d get the benefits of being able to group them, but it’s a slight kludge. Probably not a big problem though.
Could global assistants be shown in the layer docker? Maybe having the assistant mask at the top of the layer tree without being linked to a layer or group should be possible - these would be “global” and could be dragged elsewhere in the layer tree to behave as “local” assistants.
This is technically possible, and it’s already possible with Global Selection Mask. You can turn its visibility on in Select → Show Global Selection Mask.
Hi @tiar
Many thanks for this proposal 
The idea is really good, and being able to manage and organize assistants (through a layer or a dedicated assistant tree) is really interesting (at least for me)
Concerning the 1st case, having assistants on a “mask” under a layer, I have 2 questions:
-
Is it possible to have many assistants per mask, or only one assistant per mask?
– First case (many assistant available on a mask) seems to be a better possibility
– Concerning this caseWill it be possible to implement it on same mask only or using all visible/active masks for current layer?
-
If implemented through mask, don’t forget to update PyKrita API to, at least, being able to access/create/rename/delete assistant mask as it’s currently possible for all other layer/masks (at least, the basic Node class methods
– being able to create/update/delete an assistant on a mask in an another thing, even if it would be really great it’s probably not mandatory for a first released version
Grum999
2 Likes
Multiple assistants per mask. And multiple active masks per layer will be possible too 
I hope I could implement it for all active/visible masks.
I have a generic “Make assistant tools available via Python scripting” task with number F145. However I will only start it after I finish all refactoring/major technical changes in regards to assistants.
2 Likes
I can understand hulmanen’s concerns. Krita’s layer grouping already has a purpose that goes beyond mere organization, and I have my doubts that assistant visibility maps to my layer grouping somehow naturally, it’d probably be more coincidence if it fits.
Attaching to a single layer is probably not something I’d use very often, although it would be cool if attached assistants could follow layer translations/transformations automatically where possible. But linking to a layer could be achieved by other means than making it a layer “mask” too.
I’m a bit concerned that most of the time I’ll just end up having a separate assistant tree in the layers docker and need to scroll between paint layers and assistants like mad. Hence I’d prefer a separate view at least as option.
2 Likes
Thanks for the proposal and the discussion on this. It’s one of the features I am personally very exited to see. Though, like I share the same concerns as @Lynx3d and @hulmanen.
Design issues?
I see why people would like the assistant masks — to associate assistants to particular layers.
However, I am afraid that it would make managing them quite a hassle. Can assistant masks be linked across multiple layers? So consider a sketch layer and a linework layer that would both use the same assistants (perspecitive). With the current proposal, I would expect to have to duplicate the mask and nest it under the linework layer. But what if I change it in the linework layer? Do I have to copy it back to the sketch layer? And what if I move the contents of a layer with the move tool or use the transform tool, the association with the assistant mask is lost. Is that to be expected?
I don’t want to expand layers to see my assistants, nor do I want to have assistants take up a lot of screen space in the layer tree (because technically, it isn’t layer content, nor does it affect layer content like effects or masks do). They are more like guides.
Local and global assistants
I also don’t understand the local and global assistant discussion that is mentioned. Aren’t all masks local (even when applied to groups)? A layer tree/ docker, I think falls short of one particular functionality to help associate it to objects, which, I think, is why it’s not voted for as much.
What I would like to see is a cross-over between assistants and something known as master pages in Indesign/ Affinity publisher. Bare with me, text in quotes is further elaboration with examples and further details on implementation, regular text is the main explanation.
What I would do is create a docker for assistants. The assistants would be displayed in a tree like fashion, so you can create multiple presets (e.g. Preset 1 has 3-pt perspective and a couple of rulers, Preset 2 has a 2pt perspective and several ellipses).
Then you can drag a particular preset over a layer to associate it to a layer/ group. Doing so would add a coloured? text on a layer with the preset name. This so you can see that an assistant preset is applied to a layer. Dragging another preset over a layer replaces the one that was previously used.
The advantage of this approach
The main advantage is you can edit a preset, e.g. by adding or removing assistants and these assistants would then propagate to all layers/ groups to which the preset is associated.
In the assistant docker, there should be a collapsible sub-panel portion, which shows the layers to which the selected preset is assigned to.
Each of the layers to which a preset is associated should show the Parent layer/ Group (incl. thumbnail) the way it is shown in the layer docker. If you click on a layer, It’ll jump to the layer in the layer panel and zoom to the extents of the assistants in the canvas. So the docker would also link to the layers panel, not just list layers, because, there may be duplicate/ similar layer names.
I could make a mock-up, if you think it’s necessary to understand this @Tiar.
It may seem complex when I explain it in text, but I think it would be both flexible and easy to use. The global assistants would take no additional effort to set up. But it may also be a bit more involved to implement it this way…
1 Like
To use selections across all layers, you don’t need to create and duplicate a Local Selection Mask, you just use normal selections. I’m not going to remove the possibility of global/normal assistants, so if someone is not up to date with Krita’s release notes, they might just use assistants as they always used them and they wouldn’t notice a difference.
Currently, yeah, I think so… But that’s how it works right now, too. Assistants only work with drawing tools. They might work with Transform Tool in the future but probably not in this automatic way, woudl be difficult to guess what they should do in any given moment.
Well yes, but you can have a hidden, usually invisible to users mask attached to the root node that contains all layers. That’s how selections work in Krita. You can see the Global Selection Mask using Select -> Show Global Selection Mask. You can use selections not even knowing about existence of that mask.
Similarly, users will be able to use assistants not attached to any particular layer, and they will be stored in that “Global Assistant Mask” or however it will be called. If someone doesn’t wish to use assistant masks, they will be able to use assistants just as you can today.
Local = only applicable to specific group or layer.
Global = applicable to every layer in the document.
The idea of separate tree and some kind of many-to-many association (or many-to-one? Can you associate multiple assistants “presets” to one layer?) is interesting. I worry it would be a tiny bit too complex though. I will have to think about it.
2 Likes
Okay, so I did mostly understand it correctly in terms of local and global.
I wouldn’t expect to have multiple presets associated to a single layer. I would use a local preset and a global preset (or multiple global presets for that matter).
Basically, you can have one local preset, but the local preset can have multiple assistants, each is shown in the assistant tree. They can be grouped for organization purposes.
The way I’m thinking is that if you may want to be able to associate a preset to multiple comic panels and this would easily allow you to do that and enable/disable the assistants you need without losing the link to the other frames.
One thing I haven’t seen mentioned is how you would position a preset to multiple comic panels. Not to mention, some panels may be scaled up, but use the same assistants throughout. Should assistants instead be associated to artboards? And should the layer panel then show artboards? Affinity Designer does this and that’s rather nice imo. But you could also use frames (in the Indesign/ Affinity Publisher sense, where a frame is a clipping mask in which you can place content).
So for comics you would then have artboards/ frames for the individual panels and a page wide artboard for the page itself. I think I mentioned this once in the comic topic, but didn’t get a response back then. So perhaps this development ties into that to some extent for preset placement…?
I think that the complexity also stems from my experience with the Adobe & Affinity suite and the fact that my proposal is about how I would solve it if anything was possible. And yes, I do like ‘automated’ solutions where I tell the software the bare minimum it should know to accomplish a task while being able to tweak it with minimal effort afterwards too.
1 Like
Okay hear me out, random idea that popped into my head when you said that:
What if they did have a grayscale part, and that was used to define where the assistant showed up, allowing for weird comic panel shapes?
In my own opinion, either the docker or the in-layer option are both viable for my use case so I won’t chime in there.
I see many people saying they have no docker space so I’ll put my word in for the opposite, I have a perfect spot for it in my workspace. What I don’t have is layer space, I already have to go on a treasure hunt looking for the layer I want in the sometimes hundreds of layers.
Since it doesn’t have a visual aspect to it like a mask, would it be possible to make the ‘height’ of the assistant layers fixed to something reasonable? I have my layer previews rather large so I can tell what’s on them, and if the assistant layer was also that size it’d be a big waste of vertical space.
Aha, beat me to it. Shoulda finished reading the thread first.
Quick mockup for fun
Doesn’t have to be that compressed, but the main takeaway is that it doesn’t take up much space, shows up next to masks, has a hide/show button and a snap/not snap button on the right toggle panel.
3 Likes
I don’t know if it has been suggested yet, but how about giving painting assistants a filter for layer color labels to determine visibility?
Of course color labels are limited, but that way it would be completely independent of the layer structure.
2 Likes
It sounds like we’d end up with assistants being added and edited in two separate places. It seems like a source of confusion to me, if the used has to keep track of whether their assistants are in ”masks” or found under the assistant tool. Maybe I misunderstand the proposal.
Or, with large thumbnails, the two-character combination/ an icon that corresponds to an assistant/ preset could be displayed on top of the layer thumbnail. Then you wouldn’t lose screen space. I doubt anyone cares that much about seeing the whole thumbnail.
That’s actually important to have either way: local and global. Sometimes you need the assistants for the entire drawing, sometimes you may need to associate them to a layer, so anytime you draw on a layer, it’ll automatically snap to a particular (set of) assistants. Assistant snapping has to be enabled of course.
And, it’s also convenient to have the assistants behave as is (or even more accessible with less keystrokes/ button clicks). Say, for example, you need an ellipse assistant to draw a couple car tires, then you wouldn’t want to create a mask first. No, you would probably want to enable the ellipse assistant, sketch tire 1, move the assistant, sketch tire 2, etc. You could opt to save it as a mask, but that would take an additional step.
1 Like
Having thought about the implementation further, if what we need is to associate assistants to layer content (comic frames), then I am convinced that the assistants should also be transformable with the layer. Taking the car tire example again, I may want larger wheels and I would thus transform the pixel/ vector layer to scale a tire. But then, I would have to adjust the assistant too.
On other occasions you might not want to transform the assistant too, so I would then want this option available in a separate docker. Basically, I would see an assistant/ assistant preset as an item that can be overridden. Meaning it can be scaled, moved or transformed otherwise in relation to a layer, without affecting the ‘master’ assistant/ assistant preset. Instancing of assistants/ assistant presets if you will.
What I don’t quite know yet is whether I would want the assistant to be tied to the layer content’s bounding box, an artboard/ frame or that it should be transformed with the layer itself. I think that the latter would probably be most helpful and the easiest to use. And again, this behaviour should be toggleable. In a dedicated docker, it would be easier to track (for example with a paper clip icon) which assistant/ assistant preset is associated to a layer’s transforms. Though, it would also be applicable to masks for that matter. Maybe I should create a feature requests for transforming assistants with their layers? What do you think @tiar? It’s a bit tangentially related to this topic…, but good to take into consideration for the design of assistant masks/ docker.
If the assistant is a mask one could use the lock to prevent it being transformed with the layer.
To be honest, I think that someone is using so much assistants that the layer docker gets unusable or difficult to navigate then they may have bigger fundamental issues.
If one doesn’t want the long list of assistants to take space in the layer stack then they just coolapse the layer mask and manipulate the assistants on canvas. I don’t think one needs to have the assistants visible on the stack but for operations like moving it on the stack or similar.
If one really needs to reuse the same assistant mask in different parts of the layer stack the concept of clone layer could be applied, although I think that most of the time the layers that need the same assistant mask would be close together and only 1 assistant mask would be needed.
But that’s just my opinion, I don’t know everybody’s workflow. Just to keep the flow of ideas.