SUMMARY This is observed in the 5.0.0 and Jan 02 5.1.0-prealpha (git 79911ed) appimages on Debian 10. The new option, "LightnessStrength" is shown in the 'Available properties' pane of the Brush HUD Configuration window. If it is moved into the 'Current Properties' pane and OK is pressed, it does not appear in the Brush Options panel. Other properties such as Size, Opacity, etc are not affected. STEPS TO REPRODUCE See Summary OBSERVED RESULT See Summary EXPECTED RESULT It should be implemented (and also work).
I'll look into this, I've refactored this code recently to enable localization and this was one of the "special" ops that didn't match between name and variable identifier.
There are two considerations here: - Lightness Strength does not require the "Lightness" mode, but rather a RGBA brush tip. This was somehow lost in https://invent.kde.org/graphics/krita/commit/0395e4e7f16015ae3ae248943ee6a6a3bf3d100f . The check is in KisBrushOpSettingsWidget::notifyPageChanged, and KisBrush::preserveLightness(). Tested it with a the Bristles-2 Flat Rough brush with the Craig 02 tip. - Even if the property is added to the HUD, if the brush doesn't already include it, it must be first enabled in the Brush Editor before it's usable. Not sure if this is a bug or intended, so ccing Halla for a determination.
Hi, Amyspark and Ahab! That is kind of "intentional" behavior. The HUD shows properties for the brush only in case it has been enabled in the brush editor. The same UIX works for several properties in the colorsmudge engine: "Smudge Radius" and "Color Rate". t There are two reasons for this behavior choice: 1) Even if we show this slider in the GUI, the HUD will not have a control to **enable** this option. Basically, HUD has no built-in control for "a checkbox + a slider". It can only show either a checkbox **or** a slider. We can implement that, but I'm not sure about that because of the next point... 2) The HUD was intended not to be cluttered by lots of unused options. We don't want it to become a department of the brush editor :) To sum up, the current behavior is intention and works correctly. If you want to change this behavior, it is okay, but we need a proper discussion of it.
It's clear to me that I don't know enough about this to ask for any change related to it. I'll leave it to Amyspark or Dmitry (or anybody else) to do whatever they think should be done with this bug report.
Thanks for your comment! Automatically switching the status of this bug to REPORTED so that the KDE team knows that the bug is ready to get confirmed. In the future you may also do this yourself when providing needed information.