SUMMARY In the color selector you get when clicking one of the two swatches for your current colors, if you are in 32bit float depth mode and type a number into any of the fields, the color picker will disappear and, if you press ok, the corresponding swatch will go transparent. It happens as soon as you press a number key other than 0 This persists if you click in the area the color picker would appear in (values in the fields change but the picker remains invisible and the swatch won't fix itself) or if you arbitrarily change your working color space or bit depth. It goes away as soon as you click on a preset color swatch or change the color using the color picker tool. In any other bit depths (including 16 bit float) input works as intended This is independent of chosen color space STEPS TO REPRODUCE 1. open new file with 32bit depth 2. click on swatch for current color 3. in any field, type any number other than 0.00 OBSERVED RESULT Color selector disappears, color becomes invalid EXPECTED RESULT Color changes to the specified color ____________ Krita Version: 4.2.2 Languages: de, en_US Hidpi: true Qt Version (compiled): 5.12.4 Version (loaded): 5.12.4 OS Information Build ABI: x86_64-little_endian-llp64 Build CPU: x86_64 CPU: x86_64 Kernel Type: winnt Kernel Version: 10.0.17763 Pretty Productname: Windows 10 (10.0) Product Type: windows Product Version: 10
I cannot reproduce this in current master, but this might be due the fixed Lynx3d did. Can you check the latest build whenever you have the chance? And if you can still reproduce give a bit more information?
Created attachment 122786 [details] buggy swatch when triggering the bug (top swatch is invalid color)
Created attachment 122787 [details] visual shape selector doesn't update correctly
Created attachment 122788 [details] What visual shape selector should look like for example color
I have now updated to Krita version 4.3.0-prealpha (git 5f783c4) The precise behavior appears to have changed now, but still persists. Let me go through my first report point for point: > n the color selector you get when clicking one of the two swatches for your current colors, if you are in 32bit float depth mode and type a number into any of the fields, the color picker will disappear By "color picker" I meant the visual shape selector. It no longer disappears. > the corresponding swatch will go transparent. This still happens. (See attached file "Buggy Swatch [...]") > This persists if you click in the area the color picker would appear in That is no longer the case: Now that the visual shape selector no longer disappears, clicking anywhere inside it will fix this problem. Now for the new stuff: The visual color selector displays the color you manually type into the fields incorrectly. How exactly is unclear and inconsistent. See the attachment "visual shape selector doesn't update correctly" as an example. Note, the preview color on the bottom appears to actually be fully transparent. (Same as what happens in the swatch which updates to the same "color") - just for extra clarity, I also attached a third file for how the same typed-in color is actually supposed to look like (achieved by typing in the same values in other locations such as the Specific Color Selector) This happens whenever I type anything into the fields in 32bit float depth. On my first test in this new version, I briefly also found a secondary way to trigger the same issue but I can't reproduce that for now: If you use the color picker from inside the Select a Color window (rather than the one from the tool bar), sometimes the same issue seems to arise. I'm not sure when exactly though. I hope that helps. Do you need any more information?
Oh I should add: The buggy color behaves exactly as if it were completely transparent. It even shows up that way in the gradient preview
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.
Lynx3d made a fix in https://invent.kde.org/kde/krita/commit/f5dd77bf83aebe7eeb34a1fc17547f9df167df8d It should be fixed in the latest nightly tomorrow.