For your consideration: Here are a few ideas for Krita that I've come up with over the past while... Figured I should dump them here in case any of them seem useful.

KALEIDASCOPE FILTER
the multibrush feature is great, but it's a bit of a cpu/gpu hog... If the user is just trying to create a mandala-type image, having each brush stroke instantiate many brush instances is probably overkill... Working on just one part of the image and then copying it to create the same effect as the multibrush would seem to be sufficient, and wouldn't cause as many performance issues while drawing... Could a filter be created that would just copy a slice of the layer (starting at a configurable axis point, etc.) to create a kaleidascope image? That way, a filter layer could be used that updates after (rather than during) each stroke, or the user could just work on one section of the image and apply the kaleidascope filter later.

There's a kaleidascope G'MIC filter, but it's not perfect (doesn't really copy the selected slice perfectly - introduces blur...), and since it's a g'mic filter it can't be used as a filter layer.

UNDO BRUSH
It would be useful to be able to pick a point in the undo history (could default to just the last action), and have a brush that could be used to "paint" a particular region of the image back to the state it was in at that point in the undo history.

DOCKERS - MULTIPLE INSTANCES
It would be useful to be able to have multiple instances of some of the dockers... eg: reference images, preset picker, etc. If each docker had a [+] button that would launch a second instance of the same docker, that would be useful.

Use case: have one preset docker showing a particular tag with commonly used presets, and another that could be used to search and scan through all presets.

Or: using multiple reference images.

Side note: would be great to be able to drag presets from one preset docker to another and apply a tag that way - ie: destination docker is showing tagX, dragging a preset into that docker window applies tagX.

STORE PAINT COLOR PER TABLET STYLUS
When using multiple styluses with a drawing tablet, it might be useful if each stylus remembered not only the brush that was used with that stylus, but also the color... So you could switch back and forth between colors by just picking up a different tablet pen. (see the post below this one for a better idea about how to implement something like this)

SELECT - CLEAR ALL VISIBLE LAYERS
(It's possible that this can already be done and I just don't know how...) It would be useful to be able to select an area on the image, and delete all paint on all visible layers rather than just clearing the current layer... Use case: I often see a stray mark that I want to erase, but I'm not sure what layer it's on - I wind up having to click through and clearing all the layers until I hit the layer the mark is on. Not a big deal, but would be useful... (someone pointed out that you can jump to the layer where the paint is by pressing R+click)

REFERENCE IMAGE DOCKER
Better navigation would be great here - drag to pan, scrollwheel to zoom, etc. (being able to use the same navigation shortcuts as the main canvas would be great too, for consistency - space+drag to pan, ctrl+space to zoom, etc.) Currently, dragging zooms in on the dragged region - this often happens accidentally when I'm selecting colors (winds up zooming wayyyyy in when I really intended to just select a color), and I wind up having to reframe the reference image... Dragging probably shouldn't zoom, since it can happen so easily accidentally...

PRESET DOCKER USABILITY
- show the currently selected brush somewhere, with the Icon... Currently, the name of the currently selected brush is shown at the bottom left of the window, adding the icon there would be useful... There are so many presets, and often you're just looking at the icon (eg: name isn't shown in the icon view...) Seeing the icon would help the user to learn to identify the brush just from the icon.

- I often wind up having to hover over presets to see what they are. This is a bit of a pain with a drawing tablet, since holding the pointer still enough to have the tooltip come up is difficult. It would be useful to display the name of the preset that you are currently hovering over somewhere on the preset docker window rather than having to wait for the tooltip.

- As mentioned above, a second instance of the preset docker would be useful. eg: one instance could be used to scan through all the presets and the other could display commonly used presets.

- a virtual "tag" that would show commonly used presets would be useful.

- a button to clear the currently displayed tag (equivalent to the "all" item in the dropdown tag list) would be useful - easier to hit a button than to select the "all" item in the dropdown, particularly with a drawing tablet.

- the ability to add a few buttons along the top of the docker for commonly used tags would be useful - easier to switch between commonly used tags by pressing a button than by having to scroll through the dropdown list.

- currently, you have to carefully focus on the preset filter text entry field to type. Focus is lost if you move the pointer off the preset docker. It would be nice if the filter text field had focus whenever the mouse pointer is over any part of the preset docker window - so you could just start typing anywhere over the preset docker rather than having to click on the text field first.

- drag anywhere to scroll through the presets would be nice, rather than having to click and drag the scrollbar...

- showing more presets in the brush preset history window would be nice. Currently only 10 are shown. A "commonly used preset" view (showing the presets you use most often) would also be useful.

- right click option to edit the brush icon would be useful for brush development, rather than having to manually open the brush file from a file explorer... I'm having some trouble getting my brush icons to stick with some of the brushes I've developed... the icons disappear sometimes.

- right click option to delete a brush would be useful.

FAVOURITE BRUSH PRESETS
The popup pallette already provides a good way to manage this, but it might also be useful to be able to put a couple of quick-access brush preset shortcut icons somewhere to allow the user to quickly select from a few of their favourite presets - maybe a simplified version of the preset picker docker, or maybe a widget in the menu/toolbar area that could display a few preset icons with a given tag... Or maybe a few icons along the bottom of the window beside where the currently selected brush name is displayed...

Assigning hotkey shortcuts to a few favourite presets would be great too...

BRUSH PRESET "STATES"
It would be useful to be able to save a few "states" of a particular preset... Once I've developed a nice brush, I often wind up saving a few versions of the brush (larger, smaller, with slightly different settings, different sensor mappings, etc.) This leads to the preset picker being cluttered up with lots of versions of basically the same brushes. It might be a useful direction for Krita to go in in the future to allow users to save a few "states" of the same brush - that might encourage brush developers to clutter up the preset window less... One brush could have a variety of "states" instead of having to save multiple slightly different versions of the same brush...

In practice, the brush "states" would pretty much be exactly the same as a saved brush preset is now. Saved presets that are "states" would have to be able to be bound together under one main preset, and the Krita UI would have to incorporate a way for the user to select from a submenu of brush 'states', and to save new 'states' under existing presets...

"VIEW" DOCKER
The fact that you can open a second Krita window with a view of your document is great, but because it updates in realtime, having a second window open is a resource hog... Having the second view update in realtime is probably not necessary for many use cases. The "overview" docker currently only updates after the brush stroke is finished... A new "view" docker could be created based on the way the overview docker works, but with some better navigation features - drag to pan, scroll to zoom, etc. - this would allow the user to have a second view of their work without the gpu/cpu consumption of a realtime-updating second krita window.

PALETTE GENERATOR DOCKER
It would be useful to have a docker that generates appealing color schemes based on color wheel relationships - the user could enter a few colors that they want to use, and the generator could come up with a variety of different palettes (with various tints and shades) that the user could work from... Or maybe generate a palette from colours used in a reference image.

Sort of like these tools do:

http://paletton.com
http://colorschemedesigner.com/csd-3.5
http://www.degraeve.com/color-palette
https://color.adobe.com/
http://www.perbang.dk/color+scheme/

EYEDROPPER - select colours outside krita window
Currently, you can select colours in any window using the eyedropper found in the dialog window that opens when you click on the foreground color swatch. It's inconvenient to get to this eyedropper though - would be great if this "select colours outside krita window" eyedropper was added to the tools listed in the tools docker.

I can see these being useful for some people. On the "store paint color per tablet stylus," Wouldnt an easier solution be to make brushes that "save" colors? At least for us that use multiple sketch layers to add details. While on that idea, a Fill Bucket "brush" that has settings that can be saved and duplicated, this is kind of animation specific though.

tavet wrote:Wouldnt an easier solution be to make brushes that "save" colors?

That makes sense - doing it that way would also make the feature useful to people who don't use multiple styluses... Maybe a checkbox near the "eraser switch size" checkbox in the preset editor could be added - "remember brush color" or something - when checked, each brush stores its own foreground and background colors, when unchecked all brushes forget their colors, existing per-brush colors are cleared, and Krita behaves as it does now.

I often see a stray mark that I want to erase, but I'm not sure what layer it's on - I wind up having to click through and clearing all the layers until I hit the layer the mark is on. Not a big deal, but would be useful...

You can use R to jump to the layer that mark is on! hope that helps

I would lovelovelove a color scheme generator like Paletton. Even if it's a separate piece of software, it sure beats having to go online for it.

ramskulls wrote:

I often see a stray mark that I want to erase, but I'm not sure what layer it's on - I wind up having to click through and clearing all the layers until I hit the layer the mark is on. Not a big deal, but would be useful...

You can use R to jump to the layer that mark is on! hope that helps

Cool - that totally solves that problem. Thanks.

Hi zortporfman
Thanks for the suggestions.

"VIEW" DOCKER
The fact that you can open a second Krita window with a view of your document is great, but because it updates in real-time, having a second window open is a resource hog... Having the second view update in real-time is probably not necessary for most use cases. The "overview" docker currently only updates after the brush stroke is finished... A new "view" docker could be created based on the way the overview docker works, but with some better navigation features - drag to pan, scroll to zoom, etc. - this would allow the user to have a second view of their work without the gpu/cpu consumption of a real-time-updating second krita window.

The fact that it is real-time is what makes it useful. It is really helpful when you have one view zoomed out and on the other view you zoom in while paint small details (I know this can be done with overview docker but real-time speeds up things) but the most important thing is when you have one view mirrored and you draw on the second view this really helps in correct anatomical mistakes and having this real-time is really helpful rather than guess and wait for the brush stroke to appear, erase if it is wrong and then again paint.

If you don't need this behavior you can make the overview docker big enough and use that as a view, but for some of us real-time is cool. Same goes for your opinion on multi-brush, while having a kaleidoscopic filter is cool but real-time multibrush helps to connect those design other wise it would be cumbersome as one would have to draw a slice, run the filter if the strokes miss-match a bit undo the filter draw again while guessing and re-run the filter.

The rest of the suggestions are good but i am not in favor of removing the real time feature

kamathraghavendra wrote:The rest of the suggestions are good but i am not in favor of removing the real time feature

I'm not suggesting removing the realtime view, just suggesting that adding a view docker that doesn't update until the end of the brush stroke would be useful. I do a lot of multibrush stuff, and having a realtime view doubles the number of brush instances that Krita has to deal with - this can slow things down noticably. I don't need to see realtime updates for most of the work that I do, so a view that doesn't update until the end of the stroke would be great for my use case.

Also not suggesting that the multibrush be removed. Just that adding a filter would be a useful feature for some use cases. And a filter could do some things that multibrush can't do (eg: multibrush doesn't generate perfect symmetry when using a brush that's not symmetrical - angled brushes produce variation in multibrush - different parts of the multibrush image look noticably different - this is cool for some uses, but perfect symmetry would be better for some uses... Also, kaleidascope filters could generate different types of symmetry...) Here's some discussion of math used to generate a few different types of kaleidascope symmetry in Mathematica: http://mathematica.stackexchange.com/qu ... type-image

Thank you for the suggestions. The last feature, a global eyedropper is unlikely to be implemented in Krita, since it poses a security hazard. (I do not want arbitrary snooping around my screen without prompting for authorization.) This may be possible to do currently, but after the Linux graphics stack switches to Wayland it will no longer be possible without complexities like writing a compositor plugin, an option for users to disable the feature, and so on.