SUMMARY Trying to change the properties (colour, position, opacity) of a stop in the gradient editor for vector shapes keeps forcibly re-selecting the first stop. This happens whether by clicking and dragging to change position, or by expanding the colour selector from a double-click, or selecting "edit stop" in the hamburger menu. STEPS TO REPRODUCE 1. Create a vector shape on a vector layer. 2. Select it using the Select Shapes Tool. 3. Navigate to the Tool Options docker, select the Fill tab and select Gradient Fill. 4. Create some stops and start trying to edit them. Drag them around, double-click and edit the colours, or edit the properties from the hamburger menu next to the gradient preview. OBSERVED RESULT The left-most stop becomes selected and edited, making the other stops very difficult to manage. EXPECTED RESULT The stop that is clicked on should be selected. SOFTWARE/OS VERSIONS Windows: 10 (x86_64) ADDITIONAL INFORMATION
A possibly relevant merge request was started @ https://invent.kde.org/graphics/krita/-/merge_requests/1491
Git commit fc362afcb2954d10f8391f803b44a4c2ac88de39 by L. E. Segovia, on behalf of Sharaf Zaman. Committed on 28/06/2022 at 19:49. Pushed by lsegovia into branch 'master'. Bugfix: Gradient fill stops can't be changed for vector objects What resulted in the bug is firing of selectionContentChanged() signal after the setNewGradientBackgroundToShape() routine had returned -- because the blocker for d->shapeChangedAcyclicConnector had already been destroyed. And when the shapeChanged method was called, it sent down the call assuming gradient was changed (which would reset value of m_selectedStop) when it wasn't. Now, we remove signal connections for selectionChanged() and selectionContentChanged(), because they're delivered asynchronously and without proper guards (the signal blocker work only in some cases, e.g on windows they always fire once the guard lifetime has ended). Removing these signals is safe because we now use resourceManager signals to update the UI once the underlying resource has changed. Related: bug 447464, bug 449606, bug 453331 M +2 -20 libs/ui/widgets/KoFillConfigWidget.cpp https://invent.kde.org/graphics/krita/commit/fc362afcb2954d10f8391f803b44a4c2ac88de39
Git commit de938cfc89875c360a0e161b5de723739eedf2cc by L. E. Segovia, on behalf of Sharaf Zaman. Committed on 28/06/2022 at 19:52. Pushed by lsegovia into branch 'krita/5.1'. Bugfix: Gradient fill stops can't be changed for vector objects What resulted in the bug is firing of selectionContentChanged() signal after the setNewGradientBackgroundToShape() routine had returned -- because the blocker for d->shapeChangedAcyclicConnector had already been destroyed. And when the shapeChanged method was called, it sent down the call assuming gradient was changed (which would reset value of m_selectedStop) when it wasn't. Now, we remove signal connections for selectionChanged() and selectionContentChanged(), because they're delivered asynchronously and without proper guards (the signal blocker work only in some cases, e.g on windows they always fire once the guard lifetime has ended). Removing these signals is safe because we now use resourceManager signals to update the UI once the underlying resource has changed. Related: bug 447464, bug 449606, bug 453331 (cherry picked from commit fc362afcb2954d10f8391f803b44a4c2ac88de39) M +2 -20 libs/ui/widgets/KoFillConfigWidget.cpp https://invent.kde.org/graphics/krita/commit/de938cfc89875c360a0e161b5de723739eedf2cc