Selecting a color by using the right-click pop-up color selector updates the *display* of the Advanced Color Picker, but any of the 4 "square" modes with the saturation slider on top do not actually update internally. Consequently, if you attempt to use the saturation slider after using the right-click menu to change colors, the color picker will revert back to its previous hue (i.e. from before the right-click update). While testing this, I also discovered that the saturation slider in the 4 "circle with saturation slider" pickers misbehaves in a different way. While these sliders do not revert the hue after a right-click color change, 3 of them will slowly shift the hue toward cyan or red (whichever is closer) and the other one moves the color almost instantly to white. I'm not sure whether these should be filed as separate bugs, and I'd be willing to file separate reports if that would be helpful, but since they are so closely related, it seemed that a single bug entry would be most useful. Reproducible: Always Steps to Reproduce: Case 1 - color-reversion 1. Select one of the Advanced Color Pickers with a saturation slider on top and a square on the bottom (row 3) 2. Paint in any arbitrary color 3. Use the right-click color picker to change colors 4. Paint in the new color, to confirm the change (note that the Advanced Color Picker is now displaying the new color) 5. Attempt to adjust the saturation by using the slider in the Advanced Color Picker Case 2: Color snap to white 1. Select the Advanced Color Picker with the saturation slider going from gray to red on top, and a circle on the bottom (row 4, column 2) 2. Select any color other than white 3. Attempt to adjust the saturation by using the slider in the Advanced Color Picker Case 3 - hue shift toward cyan or red 1. Select one of the *other* 3 Advanced Color Pickers with a saturation slider on top and a circle on the bottom (row 4, columns 1, 3, or 4) 2. Select an arbitrary color 3. Attempt to adjust the saturation by using the slider in the Advanced Color Picker Actual Results: Case 1: Hue reverts to that of the previous color Case 2: Color almost immediately snaps to white (shift happens more slowly when 16-bit or 32-bit color spaces are used) Case 3: With each click, hue gradually shifts toward either cyan or red (whichever is closer) and then remains "stable" there Expected Results: Case 1: Hue of the current color remains the same, and saturation is adjusted to match the slider Case 2: Hue of the current color remains the same, and saturation is adjusted to match the slider Case 3: Hue of the current color remains the same, and saturation is adjusted to match the slider I'm running Krita freshly built from the git repository an hour or so ago. As far as I can tell, the only thing affected by color space and bit depth is the speed of the shift to white in case #2. I've tested RGB, CMYK, and L a* b* colorspaces with several different bit depths (although not every single permutation).
Hi Benji, Thanks for the very extensive report and sorry I didn't get back to you before. We don't have a fix yet, but I can confirm the issues.
Hi Boud Case 2 an 3: Basically makes all advanced color wheels with the color bar(HSV, HSI, HSL) no top and circle in the middle unusable/unreliable. I shifted to the saturation on top and square on bottom. Case 1 exists, but it's less annoying. I made this video to report my case. http://youtu.be/oIONEGfivYI hope this bug gets fixed soon!
Found a rare shifting using the color selector, triangle with a hue ring around. The strange thing about it is that using the Docker I get the shifting but using the palette color selector there is no shifting at all. Made a video showing that and in the end showing "case 1" http://youtu.be/0YQYq7Vf9kU This bug seems to be related https://bugs.kde.org/show_bug.cgi?id=317648
Today, I discovered that using right-click on these colour selectors does NOT reproduce the behaviour, only left-click does.
Adding to that, the behaviour is even triggered on right-click when first entering the colour selector, from either other UI elements like the canvas, but also from the shade selectors. Seems there's two weird things going on: *The left-click making the position-circle travel over the selector, regardless. *Entering the colour selector from other UI elements making the position circle travel over the selector regardless of which mouse-button is used. The latter resembles bug https://bugs.kde.org/show_bug.cgi?id=317648 I don't dare to say whether it's two bugs or one bug though.
Wolhera nice. As long as no left click is performed inside the advanced color selector docker. Using only right click solves the circle shifting problem. but it doesn't update the nib color, only docker appearance. So, Using right click avoids circle shift in the docker but only updates the color IN it, the actual brush color is unchanged.
My bad, right click selects background color. Never use it before, new finding for me :p. This makes the bug more intriguing to me. what events have the left click the right doesn't to trigger the bug?
related to bug 317648
Hi guys! Here is my test with the upper slider. It should change only Lightness. But it also changes Hue. http://www.youtube.com/watch?v=7z9YIM95Ir0&feature=youtu.be
Okay, after a lot of debugging I sort of have a grasp of where this bug is coming from. 1. It's not the mouse-events, but the foreground-colour vs background-colour change. If you switch around which mouse button activates which, the bug remains with changing the fore-ground colour. 2. It's related to a work-around for bug 275900. Foreground colour change triggers setColor in kis_color_selector_wheel.cpp, Background colour change doesn't. setColor contains the work-around to bug 275900, put this same workaround in selectColor, and the background colour change has the same bug. Comment it out in setColor, and the bug becomes less drastic on fore-ground colour change(though it still happens) Foreground-colour change: Mouse press event triggered. mouse event-triggered 222 , 151 Wheel-color-select triggered colour selected 222 , 120 QColor(AHSL 1, 0.462444, 0.721126, 0.786282) Wheel-color-select triggered colour selected 222 , 120 QColor(AHSL 1, 0.462444, 0.721126, 0.786282) Commit colour triggered. Set-colour triggered Mouse press event triggered. Commit colour triggered. Background-colour change: Mouse press event triggered. mouse event-triggered 178 , 18 colour-strip select Wheel-color-select triggered colour selected 179 , 88 QColor(AHSL 1, 0.366472, 0.556191, 0.681987) Commit colour triggered. Mouse press event triggered. Commit colour triggered. Now, as we can see, having the foreground colour updated is what triggers setColour, which then updates the foreground colour again. I suspect it's the coordinates screwing up between the setting of the foreground colour and then it being processed by setColor. So either setColor is examined more thoroughly, or the advanced colour selector shouldn't receive an update when it's the one sending it. I hope this makes any sense.
Uhm, I actually managed to fix this bug, but I have no clue how to go about making patches. The problem is indeed partially in the setColor of each colour-selector. The workaround for that other bug didn't calculate the last mouse-position correctly. One bug I couldn't fix: Qcolor doesn't return very consistent values for saturation(they seem to round off upwards?) so if you keep feeding it the same colour(which is fed to it in RGB), Qcolor will return a higher saturation value each time. Lightness and Hue seemed to have similar problems. Due to this, first picking a colour and then changing it on the colour selector will still result in a minor amount of offset. The big bandaid however is to not allow the advanced color selector to update itself. Setting a boolean on mouse-click and then having this boolean turn false on the same line as the colour-preview popup gets you consistency. Then not allowing updating the colour when the foreground colour is updated, as long that boolean is active, solves the issue.
Created attachment 84710 [details] Patch making changes as described. Alright, first patch, hope it'll work out.
Git commit efb1f19602df7c315d6e0643b60abf97946304ca by Boudewijn Rempt. Committed on 20/01/2014 at 12:25. Pushed by rempt into branch 'calligra/2.8'. Patch by Wolthera. Thanks! CCMAIL: griffinvalley@gmail.com M +8 -6 krita/plugins/extensions/dockers/advancedcolorselector/kis_color_selector.cpp M +13 -3 krita/plugins/extensions/dockers/advancedcolorselector/kis_color_selector_base.cpp M +2 -0 krita/plugins/extensions/dockers/advancedcolorselector/kis_color_selector_base.h M +1 -0 krita/plugins/extensions/dockers/advancedcolorselector/kis_color_selector_component.cpp M +13 -9 krita/plugins/extensions/dockers/advancedcolorselector/kis_color_selector_simple.cpp M +18 -3 krita/plugins/extensions/dockers/advancedcolorselector/kis_color_selector_wheel.cpp http://commits.kde.org/calligra/efb1f19602df7c315d6e0643b60abf97946304ca
This patch seems to fix bug #317648 as well. No more right click acrobatics! :D when is it planned to port this patch to master branch?
Tomorrow morning... I'll take a look at what I still need to forward port. But for now, please test 2.8! On Fri, 24 Jan 2014, vanyossi wrote: > https://bugs.kde.org/show_bug.cgi?id=309998 > > --- Comment #14 from vanyossi <ghevan@gmail.com> --- > This patch seems to fix bug #317648 as well. No more right click acrobatics! :D > when is it planned to port this patch to master branch? > > -- > You are receiving this mail because: > You are on the CC list for the bug. > You are watching the assignee of the bug. >
Git commit 70a5c784b1acd6d3030a74ab3d27e921b34aee01 by Boudewijn Rempt. Committed on 20/01/2014 at 12:25. Pushed by rempt into branch 'master'. Patch by Wolthera. Thanks! CCMAIL: griffinvalley@gmail.com M +8 -6 krita/plugins/extensions/dockers/advancedcolorselector/kis_color_selector.cpp M +13 -3 krita/plugins/extensions/dockers/advancedcolorselector/kis_color_selector_base.cpp M +2 -0 krita/plugins/extensions/dockers/advancedcolorselector/kis_color_selector_base.h M +1 -0 krita/plugins/extensions/dockers/advancedcolorselector/kis_color_selector_component.cpp M +13 -9 krita/plugins/extensions/dockers/advancedcolorselector/kis_color_selector_simple.cpp M +18 -3 krita/plugins/extensions/dockers/advancedcolorselector/kis_color_selector_wheel.cpp http://commits.kde.org/calligra/70a5c784b1acd6d3030a74ab3d27e921b34aee01