Change Details

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= - Color selector tool changes to the random colors. [ https://bugs.kde.org/show_bug.cgi?id=394396 ] - Color Pickers: First time picking a color with blending enabled on fresh Krita instance causes hue to jump to red. [ https://bugs.kde.org/show_bug.cgi?id=394399 ] =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.

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= - Fixed D12953 ~~Color selector tool changes to the random colors. [ https://bugs.kde.org/show_bug.cgi?id=394396 ]~~ - Color Pickers: First time picking a color with blending enabled on fresh Krita instance causes hue to jump to red. [ https://bugs.kde.org/show_bug.cgi?id=394399 ] =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.

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= - Fixed D12953 ~~Color selector tool changes to the random colors. [ https://bugs.kde.org/show_bug.cgi?id=394396 ]~~ - Color Pickers: First time picking a color with blending enabled on fresh Krita instance causes hue to jump to red. [ https://bugs.kde.org/show_bug.cgi?id=394399 ] =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.