For scenenario 1, yes it is cumbersome to work with assistants that need constant adjustment, however this may not be a problem with the usage but the design of the assistant. For example, ruler is good but requires to be adjusted on every stroke to make new lines, on the contrary, parallel ruler needs less input as you can do all parallel lines at once. So first we have to design the functionality of assistants to be less dependant of user input. However this is not trivial to do. On the other hand, if we could have a key to quickly activate the edit options from the closest assistant that could help mitage this issue.

Scenario 2. assistant layers could be used to group asisstants and activate only the ones you are going to use, but this situation will happen even in this scenario. Unless the algorithm can choose inteligently this will require some fast way to quickly turn the assistant on/off. If we could group assistant in layers, then its up to the user to organize overlapping assistans in different layers.

Scenario 3 Assistant layers could solve this, to avoid adding boilerplate to the creation of assistants + boundaries. But for this I have no concrete idea.

I used to work with assistans a lot and I setup a keyboard shortcut to enable disable assistants, and also to move to assistant tool quickly. It works some but it is slow, I wonder if adding assistant layers would make the workflow it slower or faster

scenerio 1) you want to make one single line or a bezier curve in a nice way and it’s done better with assistants, but to do that, you gotta go to the assistant tool, set it up, then move to the brush, enable snapping, then go to the assistant tool again to remove it -> how to make it faster/easier?

I think @vanyossi brings up a decent point about making assistants less dependent on user input, though I don't know how practical that is.
When you imagine using a real pencil and ruler, to construct a scene with complex perspective for example, frequent switching between tools is just part of the nature of the task, right?

I think Krita has a more general issue (that is also an issue in other programs too) that switching between multiple tools is generally a bit cumbersome.
The fact that we (and other programs) need a hard-coded ability to quickly switch between Brush Tool and Color Sampler Tool, is evidence of the friction involved with juggling tools.
So I'm still a proponent of (at least toying with) the idea of generalizing temporary tool invocations by allowing users to temporarily invoke any tool from any other tool. But it would take a bit of research.

At any rate, I think this is more of a tool problem than one that is specific to assistants.

(scenerio 2) you want to draw something in perspective, but you are right now drawing near the horizon, so the assistant tool has a hard time to guess which direction you want to go -> how to temporarily choose a specific assistant or a specific direction (in case of 2pp assistant) in a fast/easy way?

assistant layers (for different parts of an image)

I'm still a fan of the concept of providing a tree of assistants, though layers (lists) are probably acceptable too.

We know that even a single somewhat complex illustration can call for multiple assistants, and as the complexity of the task increases the number of assistants does to (for example, drawing something like a sloped road with dramatic shadows).
And, like you're pointing out, one of the major difficulties of juggling multiple assistants in Krita right now is the fact that they kind of interfere with eachother.
When sketching drawings like this I end up spending a lot of time jumping into the Assistant Tool to turn off one vanishing point and turn on another one, so that I know that my brush will snap to the right one.

If we can think of clever ways to help nudge Krita towards selecting the right assistant (stroke start position? direction? something else? some combination?) we might be able to really improve the workflow.

scenerio 3) assistants specific for comic panels or different parts of an image

Another thing that we know is that certain workflows, like comics, can require the use of multiple independent groups of assistants, which only makes these issues worse.

We've talked in the past about associating assistants with certain layers, but lately I've been thinking wondering if it would be possible to just treat individual assistants as a new type of node/layer.
So that when we make an assistant they actually appear as individual nodes in the Layer Box/Docker, and can be included in a group layer.
This would probably be more work than building a separate data model for assistants alone as it might require a more general concept of what nodes are, but I think the benefit would be that assistant could be easily managed along with regular layers in an intuitive way. (Say you have layers for a particular comic panel in a group, you would be able to instance assistants into that same group and limit the scope of active assistants to just the ones in that group.)

My weird ideas about nodes don't end there, but at the risk of scaring people away I'll keep quiet for now. lol 😯

At any rate, I agree that it's a safe bet to say that we need some kind of structure for composing assistants, so that users can limit easily the number of active assistants to a subset of the total number needed for the entire document.

actions + buttons on toolbar

This is a good idea, but limited by the fact that the toolbar is basically completely static and based on user configuration.

Now if Krita had a *toolbar section that changed dynamically* as different tools are selected, we could do something like this and a whole lot more! (A smarter dynamic toolbar also on my wishlist...)

@emmetoneill

We've talked in the past about associating assistants with certain layers, but lately I've been thinking wondering if it would be possible to just treat individual assistants as a new type of node/layer.

That is my current preferred idea as well, something like Local Selections (which is a mask, not a layer, which would I think would fit the usage more?). Though, other programs often have things associated with a layer - like assistants in CSP or transparency masks in CSP or PS. But then, Krita's way would be to create a new kind of node.

I'm still a fan of the concept of providing a tree of assistants.

Can you please say your arguments for that? Why would it be useful to have, what usecases would show the need for this the most, why you think it would be the most convenient, etc.? I don't really know the reasoning for that.

I guess then you could disable or enable multiple assistant at once and it would provide some structure, and you'd be able to see and manage all assistants in one docker, but that could be nearly as easily done with just a docker and a list of assistants, because the tree structure, I think, wouldn't be as useful to justify coding it all in. I can imagine some use for having one assistant be dependent on another but I don't think it's a very common use case.

But that's just my guess when I look at the idea. The assistant layers request I understand, the assistants tree, I'm not really understand, so please do tell me more about it so I can judge it better.

I think Krita has a more general issue (that is also an issue in other programs too) that switching between multiple tools is generally a bit cumbersome.
The fact that we (and other programs) need a hard-coded ability to quickly switch between Brush Tool and Color Sampler Tool, is evidence of the friction involved with juggling tools.
So I'm still a proponent of (at least toying with) the idea of generalizing temporary tool invocations by allowing users to temporarily invoke any tool from any other tool. But it would take a bit of research.

I believe there was already someone working on it even, maybe @vanyossi? I'm not sure who that was.

Hello everybody. My 2 cents are here. I give all the brave Krita users access to edit the document, coment and share. Enjoy and Help if you can ;)
https://drive.google.com/drive/folders/1UMTT6TumIXr0NurBf0rex7-podiQjxwH?usp=sharing

The SVG to create more things and adjust ideas
Templates for testing like below and give more feedback about assistants

Thanks everybody for the hard work