Change Details

= "Wide Gamut Color Selector" Docker = __Basic idea__: Re-implement **Advanced Color Selector (ACS)** docker using KisVisualColorSelector. While it may seem just a matter of replacing the widgets of the central selector and add some "glue" to connect the interfaces, the selector isn't really an encapsulated part just controlling the state of color selection. That every part of ACS basically just minds its own business and manages its own internal state is part of the issues I have with it, not just the lack of non-sRGB color spaces. The advantage of not using a central internal state is that the main selector and the shade selectors can just work in the color model of choice, but each part needs to reconstruct its state from the new KoColor. That limits precision or even gamut and requires various precautions for edge cases (e.g. undefined hue/saturation of black in RGB representation). One could try to mitigate those issues by using wide gamut float color spaces everywhere, but that makes the already tricky code even more tricky and possibly slower too. And then there's non-RGB color spaces that KisVisualColorSelector supports natively. So instead of starting a giant patchwork, the more sane solution seemed to be to just start a fresh docker from scratch, avoiding duplicate state information as much as possible and exchange colors in the model (HSX, CMYK etc.) the main selector stores internally, in float precision. Not just the selector state but also the preview popup suffers issues with having multiple instances getting out of sync with ACS docker. That approach of course drastically reduces the amount of code that can be re-used as it is, and **requires a bunch of design decisions:** == Consequences the new approach has: == - The minimal shade selector becomes tied to the color model of the main selector (HSV, HSL, HSI, HSY'). With ACS it only supports HSV to begin with, so on one hand it gains new modes, on the other hand the mode is currently linked and not independent. Conversion could be done of course with the mentioned problematic, question is, would it be worth the hassle? - How do we want to handle non-RGB color spaces in shade selections anyway? Technically, handling CMYK and Lab gradients can be implemented easily, but then it basically needs to have separate configurations. (Right now it simply does not work at all for non-RGB due to a short-sighted decision by me, but it's no big deal to change that). - Color hotkeys also need review. Right now, they have no internal state at all, and there's several bugs about them losing hue/saturation or just drifting off badly. Using the internal state would also either be restricted to modify the channels of the central color model, or keep suffering from at least the edge case issues == Things I personally don't like: == Since the decisions I'm faced with already question the possibility to just make this a drop-in replacement for ACS, I figured this is a good occasion to address a few things I never liked anyway: - No explicit foreground/background mode, if either color changes externally, it gets picked up, and using right-clicks to adjust color is extremely pen/stylus unfriendly. I also noticed many of the GUI mock-ups lately feature a FG/BG toggle, so I guess I'm not the only one. - Switching color models requires too many steps (open settings, 2 clicks to choose model from the dropdown, another two clicks to select the same selector layout with the new color model in the other popover, and finally "ok"). I'd prefer a dropdown directly in the selector where color model and layout can be changed with one click each. == Bugs/Issues uncovered in ACS == - Shade sliders have a jump in values left and right of the neutral zone, the shades inbetween can't be selected - Every element has its own color preview popup, and most of them aren't properly initialized and/or updated, causing the popup to miss information of the previous color and the last used color === Current progress: === https://invent.kde.org/mwein/krita/-/tree/wide-gamut-selector-docker [x] Basic selection through KisVisualColorSelector widget [ ] Gamut Masks (needs enhancement of KisVisualColorSelector itself) [x] Minimal shade selector: Sliders [ ] Minimal shade selector: Patches [x] Color preview popup [ ] MyPaint shade selector [x] Color history [ ] Colors from image [ ] Color hotkeys [ ] Popup variants of main selector, shade selectors, history [ ] Configuration (for all of the above)

= "Wide Gamut Color Selector" Docker = __Basic idea__: Re-implement **Advanced Color Selector (ACS)** docker using KisVisualColorSelector. While it may seem just a matter of replacing the widgets of the central selector and add some "glue" to connect the interfaces, the selector isn't really an encapsulated part just controlling the state of color selection. That every part of ACS basically just minds its own business and manages its own internal state is part of the issues I have with it, not just the lack of non-sRGB color spaces. The advantage of not using a central internal state is that the main selector and the shade selectors can just work in the color model of choice, but each part needs to reconstruct its state from the new KoColor. That limits precision or even gamut and requires various precautions for edge cases (e.g. undefined hue/saturation of black in RGB representation). One could try to mitigate those issues by using wide gamut float color spaces everywhere, but that makes the already tricky code even more tricky and possibly slower too. And then there's non-RGB color spaces that KisVisualColorSelector supports natively. So instead of starting a giant patchwork, the more sane solution seemed to be to just start a fresh docker from scratch, avoiding duplicate state information as much as possible and exchange colors in the model (HSX, CMYK etc.) the main selector stores internally, in float precision. Not just the selector state but also the preview popup suffers issues with having multiple instances getting out of sync with ACS docker. That approach of course drastically reduces the amount of code that can be re-used as it is, and **requires a bunch of design decisions:** == Consequences the new approach has: == - The minimal shade selector becomes tied to the color model of the main selector (HSV, HSL, HSI, HSY'). With ACS it only supports HSV to begin with, so on one hand it gains new modes, on the other hand the mode is currently linked and not independent. Conversion could be done of course with the mentioned problematic, question is, would it be worth the hassle? - How do we want to handle non-RGB color spaces in shade selections anyway? Technically, handling CMYK and Lab gradients can be implemented easily, but then it basically needs to have separate configurations. (Right now it simply does not work at all for non-RGB due to a short-sighted decision by me, but it's no big deal to change that). - Color hotkeys also need review. Right now, they have no internal state at all, and there's several bugs about them losing hue/saturation or just drifting off badly. Using the internal state would also either be restricted to modify the channels of the central color model, or keep suffering from at least the edge case issues == Things I personally don't like: == Since the decisions I'm faced with already question the possibility to just make this a drop-in replacement for ACS, I figured this is a good occasion to address a few things I never liked anyway: - No explicit foreground/background mode, if either color changes externally, it gets picked up, and using right-clicks to adjust color is extremely pen/stylus unfriendly. I also noticed many of the GUI mock-ups lately feature a FG/BG toggle, so I guess I'm not the only one. - Switching color models requires too many steps (open settings, 2 clicks to choose model from the dropdown, another two clicks to select the same selector layout with the new color model in the other popover, and finally "ok"). I'd prefer a dropdown directly in the selector where color model and layout can be changed with one click each. == Bugs/Issues uncovered in ACS == - Shade sliders have a jump in values left and right of the neutral zone, the shades inbetween can't be selected - Every element has its own color preview popup, and most of them aren't properly initialized and/or updated, causing the popup to miss information of the previous color and the last used color === Current progress: === working branch: https://invent.kde.org/mwein/krita/-/tree/wide-gamut-selector-docker-refactor (old branch: https://invent.kde.org/mwein/krita/-/tree/wide-gamut-selector-docker ) [x] Basic selection through KisVisualColorSelector widget [ ] Gamut Masks (needs enhancement of KisVisualColorSelector itself) [x] Minimal shade selector: Sliders [ ] Minimal shade selector: Patches [x] Color preview popup [ ] MyPaint shade selector [x] Color history [ ] Colors from image [ ] Color hotkeys [ ] Popup variants of main selector, shade selectors, history [ ] Configuration (for all of the above)

= "Wide Gamut Color Selector" Docker = __Basic idea__: Re-implement **Advanced Color Selector (ACS)** docker using KisVisualColorSelector. While it may seem just a matter of replacing the widgets of the central selector and add some "glue" to connect the interfaces, the selector isn't really an encapsulated part just controlling the state of color selection. That every part of ACS basically just minds its own business and manages its own internal state is part of the issues I have with it, not just the lack of non-sRGB color spaces. The advantage of not using a central internal state is that the main selector and the shade selectors can just work in the color model of choice, but each part needs to reconstruct its state from the new KoColor. That limits precision or even gamut and requires various precautions for edge cases (e.g. undefined hue/saturation of black in RGB representation). One could try to mitigate those issues by using wide gamut float color spaces everywhere, but that makes the already tricky code even more tricky and possibly slower too. And then there's non-RGB color spaces that KisVisualColorSelector supports natively. So instead of starting a giant patchwork, the more sane solution seemed to be to just start a fresh docker from scratch, avoiding duplicate state information as much as possible and exchange colors in the model (HSX, CMYK etc.) the main selector stores internally, in float precision. Not just the selector state but also the preview popup suffers issues with having multiple instances getting out of sync with ACS docker. That approach of course drastically reduces the amount of code that can be re-used as it is, and **requires a bunch of design decisions:** == Consequences the new approach has: == - The minimal shade selector becomes tied to the color model of the main selector (HSV, HSL, HSI, HSY'). With ACS it only supports HSV to begin with, so on one hand it gains new modes, on the other hand the mode is currently linked and not independent. Conversion could be done of course with the mentioned problematic, question is, would it be worth the hassle? - How do we want to handle non-RGB color spaces in shade selections anyway? Technically, handling CMYK and Lab gradients can be implemented easily, but then it basically needs to have separate configurations. (Right now it simply does not work at all for non-RGB due to a short-sighted decision by me, but it's no big deal to change that). - Color hotkeys also need review. Right now, they have no internal state at all, and there's several bugs about them losing hue/saturation or just drifting off badly. Using the internal state would also either be restricted to modify the channels of the central color model, or keep suffering from at least the edge case issues == Things I personally don't like: == Since the decisions I'm faced with already question the possibility to just make this a drop-in replacement for ACS, I figured this is a good occasion to address a few things I never liked anyway: - No explicit foreground/background mode, if either color changes externally, it gets picked up, and using right-clicks to adjust color is extremely pen/stylus unfriendly. I also noticed many of the GUI mock-ups lately feature a FG/BG toggle, so I guess I'm not the only one. - Switching color models requires too many steps (open settings, 2 clicks to choose model from the dropdown, another two clicks to select the same selector layout with the new color model in the other popover, and finally "ok"). I'd prefer a dropdown directly in the selector where color model and layout can be changed with one click each. == Bugs/Issues uncovered in ACS == - Shade sliders have a jump in values left and right of the neutral zone, the shades inbetween can't be selected - Every element has its own color preview popup, and most of them aren't properly initialized and/or updated, causing the popup to miss information of the previous color and the last used color === Current progress: === working branch: https://invent.kde.org/mwein/krita/-/tree/wide-gamut-selector-docker-refactor (old branch: https://invent.kde.org/mwein/krita/-/tree/wide-gamut-selector-docker ) [x] Basic selection through KisVisualColorSelector widget [ ] Gamut Masks (needs enhancement of KisVisualColorSelector itself) [x] Minimal shade selector: Sliders [ ] Minimal shade selector: Patches [x] Color preview popup [ ] MyPaint shade selector [x] Color history [ ] Colors from image [ ] Color hotkeys [ ] Popup variants of main selector, shade selectors, history [ ] Configuration (for all of the above)