Skip to content

Draft: Wide Gamut Color Selector additions

Mathias Wein requested to merge mwein/krita:wide-gamut-selector-docker-features into master

This adds some more display/layout options.

Since it was requested a few times, I added the option to show the Hue + Saturation plane as triangle rather than diamond shape. There's a small caveat though: Since I originally added the diamond in order to have color model (HSV/HSL/HSI/HSY) and selector shape as independent settings, you can't put triangle AND diamond in your favorite list, it's a separate setting:

wg_triangle_vs_diamond

Otherwise I'd need to redesign the whole configuration...

Other changes:

  • You could not have the MyPaint shade selector or no shade selector at all in the docker, they're now both optional
  • Added the possibility to lay out selectors horizontally. This is different from Advanced Color Selector though. There is no automatic switch or hiding, because I figured doing it in a proper way (reason is basically next bullet) requires a specialized layout class that essentially needs to duplicate most of code from QBoxLayout (which is A LOT), deriving does not work as the crucial parameters are all private 😞
    So it's a plain horizontal/vertical choice for "Central Layout" (General Settings).
  • I added a vertical mode to the minimal shade selector, something that Advanced Color Selector was lacking and thus horizontal layout was only possible with MyPaint selector.
  • MyPaint selector now actually cares about the reset options, like resetting base color on right-click, after every interaction etc. should now work.

HSL_triangle_vertical_sliders

Test Plan

I'm mainly concerned that the settings dialog gets too cluttered and confusing here, so check if things make sense, and do what you expect from them.

And double-checking functionality of HSL/HSI/HSY triangle, vertical shade sliders and MyPaint selector.

Formalities Checklist

  • I confirmed this builds.
  • I confirmed Krita ran and the relevant functions work.
  • I tested the relevant unit tests and can confirm they are not broken. (If not possible, don't hesitate to ask for help!)
  • I made sure my commits build individually and have good descriptions as per KDE guidelines.
  • I made sure my code conforms to the standards set in the HACKING file.
  • I can confirm the code is licensed and attributed appropriately, and that unattributed code is mine, as per KDE Licensing Policy.

Reminder: the reviewer is responsible for merging the patch, this is to ensure at the least two people can build the patch. In case a patch breaks the build, both the author and the reviewer should be contacted to fix the build. If this is not possible, the commits shall be reverted, and a notification with the reasoning and any relevant logs shall be sent to the mailing list, kimageshop@kde.org.

Merge request reports