Bug 449468

Fill layers are incredibly powerful thanks to their built-in alpha mask functionality. You can basically do paintings where each color is on their own layer and change those colors out on the fly to get dramatically different results. This is very useful, especially for texture and concept artists who want to leverage their painting to allow for color variants of a work with minimal effort and a fine level of control over the results.

The main problem with the current workflow is that it takes several keystrokes/mouse clicks to change a fill layer's color, as it is buried in the layer properties pop-up. Not a big deal if you only need to change one or two colors, but in real use cases it is common to have a dozen or more fill layers that need to be adjusted to make a color variant of an image.

So my current proposed solution is to add a color picker pop-up that can be accessed by a custom user-specified shortcut. It can be left unbound by default, as to not interfere with users' current setups unless they specifically want to leverage this feature. My suggestion would be to call it Fill Layer Color Selector and to place the entry under either Krita > Layers or Krita > General in the shortcuts tab of the user preferences window.

There's already a simple color selector pop-up available, separate from the fancy full feature one with the brush palette and such, that can be an ideal starting point for anyone looking to implement this. (For me the current one shows up by using shift+I by default, found in the shortcut settings under Krita > General > Show color selector.) The main changes that would need to be made to a variant of that is to target the currently selected fill layer's color value instead of the brush color and to make it silently fail to open if a fill layer is not selected.

This is a proposed alternative to a previous feature request I made a few years back: https://bugs.kde.org/show_bug.cgi?id=412928

Since that is pretty old now and in an entirely different category from my currently proposed solution, it made sense to create a new ticket in the appropriate location and reference back to the old one, instead of drastically changing the old ticket. Mostly because I think the docker solution would still be useful, on the off chance anyone ever decided to try to address this problem from that direction as well, so worth keeping it around as is.