Color Picker Improvements and Refactoring.
Open, LowPublic

Description

I've made this task to compile feedback, suggestions, bug reports, feature/design ideas, and any other discussion pertaining to Krita's "Color Selector Tool" in order to come up with a list of goals for future development.


Known Bugs

Current Goals

  • Refine "color picker blending" feature based on peer/user feedback.
  • Refactor and unify existing color pickers by getting rid of code duplication (kis_tool_colorpicker & kis_tool_utils).
  • (Experimental) Research potential Tool system improvements for hot swapping of tools.

Goal #1: Refine color picker blending

The Color Picker's blend feature (D11895) has been in Krita for a little over a month now, and I'm hoping to collect as much feedback as possible for potential improvements or necessary changes. I've only had time to test it out in a handful of casual paintings, but I still really like it and I already have some thoughts about how its workflow and usability might be improved in the near future. Having said that, I'm definitely biased. So, have you used it? What did you think? Do you intentionally avoid using it? Why?

Goal #2: Refactor and unify existing color pickers

As of right now, Krita effectively has two near-duplicate paths when it comes to color picking code: the code for the dedicated Color Selector Tool (P) exists mainly in "kis_tool_colorpicker", while the code for the ctrl-key activated color picker that you can pull up while other tools are active exists mainly in "kis_tool_utils". This is obviously error-prone and makes it harder to develop and maintain. I'd like to find a way to fix this by refactoring and unifying all of the most important color picker code in one central location: either kis_tools_colorpicker, kis_tools_utils, or somewhere else. I'll have to study the code a bit more to determine the most effective way of doing within Krita's current design, but one potential solution that comes to mind right off the bat would be to offload all of the implementation details to a namespace function somewhere reasonable.

Update #1: D12941 Unified majority of previously duplicated code in a single location, KisToolUtils::pickColor( ... ) namespace function within kis_tool_utils.cpp.

Goal #3: (Experimental) Research potential Tool System improvements for hot-swapping of tools.

Part of the reason that the code could stand to be refactored at all is because the color picking functionality that exists within the other tools (specifically, in kis_tool_utils) attempts to recreate the exact functionality of the dedicated Color Selector Tool (kis_tool_colorpicker) instead of simply "hot-swapping" tools when the user hits Ctrl and returning to the original tool when the user releases the button. In other words, I'd argue that "Goal 2" above is simply a bandage solution, and that some research should be done into a more fundamental fix - using modifier keys to allow *seamlessly* and *smoothly* hot-swapping between actual tools instead of the current ad-hoc approach. Aside from the immediate benefit to Krita developers of not having to deal with hidden and duplicated code, another potential benefit to actual hot-swapping of tools would be that things like the Tool Docker would change on the fly to better reflect the current state of your tool (you'd always see the color picker tool options while picking colors, for example). So, after doing the bandage solution listed in "Goal 2", I want to do some research into the broader tool system to see if potential consistency, usability, and code-reuse improvements can be made.


Please let me know what you think of the Color Picker's current features (including blending, radius, palette integration, etc.) as well as any known bugs or any other design suggestions.

emmetoneill updated the task description. (Show Details)May 15 2018, 4:18 AM
emmetoneill updated the task description. (Show Details)May 17 2018, 6:51 PM
emmetoneill updated the task description. (Show Details)May 17 2018, 6:53 PM
emmetoneill updated the task description. (Show Details)
emmetoneill updated the task description. (Show Details)May 18 2018, 4:01 AM
emmetoneill updated the task description. (Show Details)May 18 2018, 4:37 AM
emmetoneill updated the task description. (Show Details)May 18 2018, 5:27 AM
emmetoneill added a comment.EditedMay 18 2018, 5:35 AM

Color selector tool changes to the random colors. [ https://bugs.kde.org/show_bug.cgi?id=394396 ]

Relating to this bug. It appears to be specific to double-clicking with a mouse while using the ctrl-picker. I haven't been able to reproduce it with my tablet, or with the dedicated color picker tool.

Krita spits out an error message whenever this happens:

krita.input: KisAbstractInputAction "Alternate Invocation" tried to process event data from an unhandled event type QEvent::Type(MouseButtonDblClick)

I've tracked this error message back to the KisAbstractInputAction::eventPos function's default switch behavior. It seems to simply be failing to catch the "MouseButtonDblClick" event.

emmetoneill updated the task description. (Show Details)May 18 2018, 6:24 AM
emmetoneill triaged this task as Low priority.
emmetoneill edited projects, added Krita: Abyss; removed Krita.May 18 2018, 8:36 PM
emmetoneill added a comment.EditedJun 28 2018, 1:35 AM

Reddit user Rous2 suggested the possibility of pressure sensitive color picker mixing (blend).

emmetoneill updated the task description. (Show Details)Aug 1 2018, 3:22 AM

Add of adjust a KisSignalCompressor with configurable sensitivity.