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
The bug is also present in 4.2.9
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.
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
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
Wow, could this be the whole story behind my free brush tool "randomly" turns 0 Opacity? Anyway, thank you Dmitry! :D
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