Bug 421752

Summary: Stroke Selection's Fill doesn't work
Product: [Applications] krita Reporter: Tyson Tan <tysontanx>
Component: Tools/SelectionAssignee: Dmitry Kazakov <dimula73>
Status: RESOLVED FIXED    
Severity: normal CC: dimula73, halla
Priority: NOR    
Version First Reported In: 4.3.0-beta1   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description Tyson Tan 2020-05-19 03:46:12 UTC
Edit -> Stroke Selection dialogue has a Fill function, but it doesn't seem to fill anything regardless of its setting.

Tested: krita-4.3.0-beta1-2000148-x86_64.appimage
Comment 1 Dmitry Kazakov 2020-06-11 20:17:49 UTC
The bug is also present in 4.2.9
Comment 2 Dmitry Kazakov 2020-06-11 20:34:46 UTC
The problem happens because when activating a selection tool, opacity is automatically reset to 0. Therefore noting is painted.

There is a workaround for the bug: one should activate brush tool before calling "Stroke Selection" dialog.
Comment 3 Dmitry Kazakov 2020-06-11 21:25:24 UTC
Git commit a5e32be9473fd50aa8a60baf3c5f0ecc0c6a3617 by Dmitry Kazakov.
Committed on 11/06/2020 at 21:25.
Pushed by dkazakov into branch 'krita/4.3'.

Fix "Stroke Selection" when any selection tool is activated

This patch is a bit hackish. The actual bug is caused by the per-tool
opacity patch (6daf2cb7), which is still planned to be refactored.

The problem is that we store opacity and the preset(!), not in the
resource server itself. Therefore, if any paint tool is first activated
when there is no preset available, then it will remember default opacity
(which was 0.0 before this patch) and all non-painting tools will use this
opacity as default.

In the future we should refactor per-tool opacity, so that it would not
write to the presets (which makes them dirty when switching tools, which
is a bug). The non-painting tools should have some flag, that would tell
the resource provider that the opacity should be stored not in the preset,
but separately.

M  +1    -1    libs/ui/kis_derived_resources.cpp

https://invent.kde.org/graphics/krita/commit/a5e32be9473fd50aa8a60baf3c5f0ecc0c6a3617
Comment 4 Dmitry Kazakov 2020-06-11 21:25:39 UTC
Git commit 988bd201893e3f005d3d11c7adca0ba55c57b0ba by Dmitry Kazakov.
Committed on 11/06/2020 at 21:25.
Pushed by dkazakov into branch 'master'.

Fix "Stroke Selection" when any selection tool is activated

This patch is a bit hackish. The actual bug is caused by the per-tool
opacity patch (6daf2cb7), which is still planned to be refactored.

The problem is that we store opacity and the preset(!), not in the
resource server itself. Therefore, if any paint tool is first activated
when there is no preset available, then it will remember default opacity
(which was 0.0 before this patch) and all non-painting tools will use this
opacity as default.

In the future we should refactor per-tool opacity, so that it would not
write to the presets (which makes them dirty when switching tools, which
is a bug). The non-painting tools should have some flag, that would tell
the resource provider that the opacity should be stored not in the preset,
but separately.

M  +1    -1    libs/ui/kis_derived_resources.cpp

https://invent.kde.org/graphics/krita/commit/988bd201893e3f005d3d11c7adca0ba55c57b0ba
Comment 5 Tyson Tan 2020-06-12 01:48:06 UTC
Wow, could this be the whole story behind my free brush tool "randomly" turns 0 Opacity? Anyway, thank you Dmitry! :D
Comment 6 Dmitry Kazakov 2020-06-12 14:33:19 UTC
Git commit 3d6a2df9a429ee77a7b2abe20ace14b696219a7c by Dmitry Kazakov.
Committed on 12/06/2020 at 14:32.
Pushed by dkazakov into branch 'krita/4.3.0'.

Fix "Stroke Selection" when any selection tool is activated

This patch is a bit hackish. The actual bug is caused by the per-tool
opacity patch (6daf2cb7), which is still planned to be refactored.

The problem is that we store opacity and the preset(!), not in the
resource server itself. Therefore, if any paint tool is first activated
when there is no preset available, then it will remember default opacity
(which was 0.0 before this patch) and all non-painting tools will use this
opacity as default.

In the future we should refactor per-tool opacity, so that it would not
write to the presets (which makes them dirty when switching tools, which
is a bug). The non-painting tools should have some flag, that would tell
the resource provider that the opacity should be stored not in the preset,
but separately.

M  +1    -1    libs/ui/kis_derived_resources.cpp

https://invent.kde.org/graphics/krita/commit/3d6a2df9a429ee77a7b2abe20ace14b696219a7c