Currently, the only settings you can change for the freehand brush tool in the Tool Options docker is Brush Smoothing and Snap to Assistants.
The On-Canvas Brush Editor docker (only available in Krita 5.3 pre-alpha at the moment) allows the user to modify many aspects of a brush preset and allows the user to modify what settings to display in the docker.
Proposal
Create an optional toggle to merge the On-Canvas Brush Editor docker and the Tool Options docker to save UI space for artists. This could be achieved by relabeling the On-Canvas Brush Editor as the new Tool Options docker and adding the Brush Smoothing and Snap to Assistants as available properties in the configuration window (added by default to avoid confusion for Krita users).
Then, when a tool other than the freehand brush tool is selected, the tool options should be shown in the docker.
In my implementation I have the Tool Options docker show within the On-Canvas Brush Editor docker when the freehand brush tool is not selected.
How it can be toggled on
Previously I proposed that the merging of the two dockers should be the new default. However this would serve to confuse existing Krita users so the merged docker should instead be an optional setting accessed in Kritaâs settings menu:
When toggled on, the Tool Options docker will display the On-Canvas Brush Editor docker when the Freehand Brush tool, Shapes tool (Rectangular, Elliptical, etc.), and MultiBrush tool is active. This means that the On-Canvas Brush Editor docker will no longer be a separate docker when the âMerged Dockerâ setting is turned on.
Why create this option?
The On-Canvas Brush Editor docker always displays brush settings regardless of whether the user has a different tool selected, this means that an artist must have both On-Canvas Brush Editor docker and Tool Options docker open if they wish to be able to configure settings for their brushes (without pressing f5) and other tools that require the Tool Options docker. With both dockers merged, an artist only needs one docker to access all their relevant tool options when they need it (the currently selected tool) while also allowing them to access more brush settings within their docker without the need to have a separate docker open. This would also make Krita more appealing to CSP users as their Tool Options docker equivalent behaves this way:
I was considering creating a merge request for this but wanted peopleâs thoughts on this before doing so. Feel free to vote if you want this in Krita or let me know if you see a flaw in this, thanks for reading.
Why remove the ability to have the original/current Tool Options docker for people who want it?
A modified On-Canvas Brush Editor docker could have the Tool Options information added as you described so that people who want it could have it and they could then remove the original Tool Options docker from their UI.
People who want the original Tool Options docker could stay as they are.
It would be a good idea to keep the on-canvas brush editor content for all painting tools because the geometric shape painting tools could use e.g. Opacity, Size, Spacing to modify the appearance of the shape outline stroke.
I think it makes sense to merge these two dockers and have all the brush options in one single docker instead of scattered throughout a couple ones. Iâd even go as far as adding the brush blending mode into the tool options docker instead of the toolbar (or at least having the ability to display or hide certain options in the docker like in CSP ). The blending mode would still be one click away if the tool options is set to be displayed on docker instead of toolbar. IIâm keeping this thread in mind and will come back if I ever have better suggestions. This feature is worth improving and thanks again for your commitment to make krita better !
It would be a good idea to keep the on-canvas brush editor content for all painting tools because the geometric shape painting tools could use e.g. Opacity, Size, Spacing to modify the appearance of the shape outline stroke.
Thatâs something I didnât consider, but it can be easily solved by showing the relevant brush settings alongside shape tool settings in the docker:
Clip Studio Paint already does this in addition to letting you add what settings to see for all tools, not just Brushes like the On-Canvas Brush Editor docker. Here you can see their shape tool settings which also shows brush settings:
Their Tool Options docker allows users to tailor the docker to show relevant settings for the user for every tool, which is not a part of the proposal but important to note on how Kritaâs Tool Options docker falls behind in that aspect currently:
Also, you havenât considered that some users may prefer to use toolbar sliders rather than the on-canvas brush editor for their shape tool settings:
A final implementation would give users the choice of what brush settings to display while they are using a shape tool. This wold allow you to add all your brush tool settings alongside your âtool optionsâ settings or you could choose to not have them on at all and delegate your settings to toolbar sliders.
Why remove the ability to have the original/current Tool Options docker for people who want it?
The intention of the proposal is to merge them into one docker without losing functionality and show all relevant settings depending on your currently selected tool. I I think the more important question to ask is do we really need 2 dockers to accomplish the same thing? I think the answer is no and that it could be simplified to benefit existing Krita users by saving UI space and benefit newcomers by making the UI easier to understand. The On-Canvas Brush Editor docker is powerful and can be merged with the Tool Options docker at no cost.
I did consider that but my Toolbar is almost full and I wouldnât want to add an extra line to it.
Anybody who wants to could do that easily. I like flexibility and options.
The Default (as installed) workspace could be changed so that the On-Canvas Brush Editor was present and the original Tool Options was not present but available for those who want it.
I like flexibility and options.
The original Tool Options docker could be left as it is at no cost. (You wouldnât have to use it if you didnât want to.) I like flexibility and options.
You donât seem to understand what my proposal is. The purpose of the merge is to give users the flexibility to keep their Tool Options docker the same, or add additional settings to the docker when the Brush tool and Shapes tool (On-Canvas Brush Editor docker) is active. This would save UI space, give existing Krita users more options within one docker, and make it more approachable for new users (they wouldnât have to look through both the Tool Options docker and the verbosely named On-Canvas Brush Editor docker).
I do understand what your proposal is, Iâve read it and looked at it very closely. Iâve also studied the existing facilities of the On-Canvas Brush Editor in 5.3.0.
All Iâm saying is that Iâd like the existing Tool Option docker to be available even if itâs not present by default. However, what happens will happen and Iâll get used to it, as usual.
But if both are merged, does that mean the panel will no longer be in Popup Palette? Wouldnât that be bad for users who use that feature?
I mention this because I use that feature, not to mention that I moved the options docker to the panel and activate it with a shortcut. Iâm mostly in âcanvas onlyâ mode.
if both are merged, does that mean the panel will no longer be in Popup Palette?
I understand where youâre coming from because the current behavior of the Brush Editor docker is that opens up in the Popup palette and its docker becomes empty, showing the user a notification like so:
I think in my proposal one docker should be strictly for the popup palette (not an additional docker that can be docked, it will strictly reside within the popup palette) and another for the merged tool options docker. So in an edge case scenario it could allow for some redundant UI if the user chooses to like this:
Current Tool Options docker vs. merged Tool Options docker ONLY when the currently selected tool is the freehand brush tool. Other tools will not have additional UI space taken up at the top of the docker:
Another question: what about the dynamic brush tool? Does it also benefit from this?
I mention this because I didnât see it in the demonstrations. I would like it to have more options as well, since I actually use it instead of the freehand tool, mainly because of the stabilizer.
I think the 4 settings (Type, Origin, Rotation, Brushes) could become one âMultibrushâ property that does not appear unless the Multibrush tool is currently active. This property would be included by default of course so there would be no difference from the current Tool Options docker.
Turning the Multibrush settings into a property would allow you to reorder all of your brush settings in the docker instead of having the Multibrush settings hard coded to the bottom of the docker.
Are you suggesting allowing the user to toggle on/off keeing the brush editor docker and tool options docker separate (like they currently are) or merged (like in my proposal)?
Apologies for being stubborn earlier. While I would personally like it merged by default, I see now it would unnecessarily revoke the option to keep their Tool Options docker the same as they are currently.
What if the merged Tool Options docker would be an optional mode? It would be an opt-in setting so you wouldnât be surprised when you open up Krita 6.1, and users who want them merged can do so in the settings menu.
I might be misunderstanding your objective, but I am under the presumption that your merge will effect the pop-up palette only. There are Krita users, who do not use or want to use this part of the application. This being said, wouldnât Krita need to have accommodations for these users also. Will this proposed merge be across both pop-up palette and the standalone dockers or will Krita need to keep the old dockers for those wishing to use no pop-up palette?
Thank you for working out a possible solution. Thatâs not what I first thought of:-
Iâm not a developer but my (possibly naive) assumption is that it would be easy to leave the âold Tool Optionsâ docker alone (there are many docker in krita, some of which Iâve never used) and have it in the list of many available dockers so that anyone who wants it can select it to be in the UI and bake it into their custom workspaces.
The new development âmerged dockerâ can be truly new and be the docker that is present in a fresh installation in the same way that the existing âoldâ Tool Options docker is present in a fresh installation because itâs in the Default workspace. So change the Default workspace to have only the ânew mergedâ docker present.
I would then be able to have the âoldâ Tool Options docker if I wanted it because Iâd know about it.
New users wouldnât know it was available unless they went looking and decided to try it.
The new âmergedâ docker could, if desired be named as the âTool Optionsâ docker and the âoldâ Tool Options docker could be renamed as âOld Optionsâ or whatever, if desired.
As I said, thatâs my naive assumption but if itâs a matter of selecting an option in the settings then that would work out ok as well in terms of the end result.
The intention of the merge is to only affect the Tool Options docker by giving it the same functionality as the On-Canvas Brush Editor docker when the brush tool is active (since the Tool Options docker currently only shows 2 settings when the brush tool is active).
btw I have been migrating for weeks to using mostly the pop-up palette. I was doing this before downloading 5.3 to try out. I voted for the merge, but was just wondering about those who donât like the pop-up palette. As I said above, the way I am reading this seems to be only the pop-up palette, but I may be misunderstanding. And as I was writing this you replied helping realize that. Thank you. I think I was looking at only the words âOn Canvas Editorâ and the images of the Pop-up Palette and that was throwing me off.
I havenât used the pop-up palette extensively in 5.3. I assume you can add the Tool Options docker to the popup palette? If so, then the merged Tool Options docker would be able to appear as a standalone docker or within the popup palette when the popup is invoked just like the current On-Canvas Brush Editor docker.
