Bug 399127

I can reproduce this, but only if I select the radial option for the gradient in the stroke tab.

I've started to use Linux Mint 19 Cinnamon lately, and this problem is reproduceable in there too. It happens on both linear and radial gradient.

Created attachment 115741 [details]
(Video example)

(Krita 4.2.0-pre-alpha (git a2ae7f3)

Try to do (see video):

    1. "CTRL + N" (new document)
    2. and create a shape

Actual Results:

    - The stroke of a newly created shape is always "none" in Tool Options

    - The stroke of a newly created shape, if visible, uses the foreground color (instead of the background)

    - The stroke of a newly created shape, if visible, and changed to "solid", makes the background color the same as foreground

    - The stroke of a newly created shape, if not visible, and changed to "solid", makes the background color "White"

    - The stroke of a newly created shape, if changed to "solid + gradient + solid + gradient", eventually changes the fill of the shape.

Created attachment 115742 [details]
(correct video example)

*** Bug 403876 has been marked as a duplicate of this bug. ***

Is this still an issue. I recently did a fix a few days ago reworking how vector object fills and strokes are applied and calculated. 

It seems to be ok in my latest git master.

(In reply to Scott Petrovic from comment #6)
> Is this still an issue. I recently did a fix a few days ago reworking how
> vector object fills and strokes are applied and calculated. 
> 
> It seems to be ok in my latest git master.

Still there. Switching between the radial / linear options for the gradient make the object filled with color. 

Plus, I've found more issues probably related to this : 
- Playing around with this behavior minimize the line thickness to 1px at certain point.
- Select the vector object (Fill = None) with the Select Shapes Tool -> Select any color in Advanced Color Selector docker = Makes the object filled with the color.

ahh got it. I was testing by what the bug report title was, and what the video was reporting. That part seems to be fixed by my testing. 

I will take a look at the switch between radial and linear why that is changing the fill. Maybe we can close this ticket once that is fixed to avoid further confusion. You can always open another one if you find something else.

I think for the second issue you mention, we probably need to discuss it with some artists before anything is changed. Some people want the color selectors to assign colors, so I am not sure if it should be ignored. See https://bugs.kde.org/show_bug.cgi?id=381784

I am un-assigning this from myself for now. I started looking into the issue with gradient strokes being changed from radial to linear, but the code is using some template stuff I am not understanding what is going on, or know how to change.

I think the issue is something going on in this function
KoShapeFillWrapper.cpp::374 KUndo2Command *KoShapeFillWrapper::setGradient

I have no idea why code specific to stroke handling is touching the fill. Dmitry wrote this area...so maybe he has some ideas

This does not happen on macos.

but the stroke gradient seems to be linked to the fill gradient in someway that if the stroke fill is set, sometimes the gradient fill style from one shape gets copied to another shape just by selecting.

A possibly relevant merge request was started @ https://invent.kde.org/graphics/krita/-/merge_requests/784

Git commit 1fffa7e33fb5581e2f379dc77101aa712830bc01 by Dmitry Kazakov, on behalf of Sharaf Zaman.
Committed on 01/04/2021 at 05:48.
Pushed by dkazakov into branch 'master'.

Bugfix: Inconsistent stroke fill and shape fill

Problem: Embedding KoFillConfigWidget in KoStrokeConfigWidget created
codepaths which KisAcyclicSignalConnector doesn't block, which resulted
in an inconsistent behavior when both strokes and fill were used in a
shape.

Solution: By default if we hadn't embedded the widgets, signals from
ResourceManager would've been blocked by KisAcyclicSignalConnector when
we entered slotProposeCurrentColorToResourceManager. Since we don't, we
have to manually block events when we are in this method.
Related: bug 422204, bug 434828

M  +8    -0    libs/ui/widgets/KoFillConfigWidget.cpp

https://invent.kde.org/graphics/krita/commit/1fffa7e33fb5581e2f379dc77101aa712830bc01

Git commit 69ac8b85e49bcd11d100a770549d4c89fecae5a8 by Sharaf Zaman.
Committed on 08/06/2021 at 07:21.
Pushed by szaman into branch 'krita/4.3'.

Bugfix: Inconsistent stroke fill and shape fill

Problem: Embedding KoFillConfigWidget in KoStrokeConfigWidget created
codepaths which KisAcyclicSignalConnector doesn't block, which resulted
in an inconsistent behavior when both strokes and fill were used in a
shape.

Solution: By default if we hadn't embedded the widgets, signals from
ResourceManager would've been blocked by KisAcyclicSignalConnector when
we entered slotProposeCurrentColorToResourceManager. Since we don't, we
have to manually block events when we are in this method.
Related: bug 422204, bug 434828
(cherry picked from commit 1fffa7e33fb5581e2f379dc77101aa712830bc01)

M  +8    -0    libs/ui/widgets/KoFillConfigWidget.cpp

https://invent.kde.org/graphics/krita/commit/69ac8b85e49bcd11d100a770549d4c89fecae5a8

Git commit 27a6d0eebce1c9fa29ddd023d5df898da01f27e6 by Sharaf Zaman.
Committed on 08/06/2021 at 07:26.
Pushed by szaman into branch 'krita/4.4.5'.

Bugfix: Inconsistent stroke fill and shape fill

Problem: Embedding KoFillConfigWidget in KoStrokeConfigWidget created
codepaths which KisAcyclicSignalConnector doesn't block, which resulted
in an inconsistent behavior when both strokes and fill were used in a
shape.

Solution: By default if we hadn't embedded the widgets, signals from
ResourceManager would've been blocked by KisAcyclicSignalConnector when
we entered slotProposeCurrentColorToResourceManager. Since we don't, we
have to manually block events when we are in this method.
Related: bug 422204, bug 434828
(cherry picked from commit 1fffa7e33fb5581e2f379dc77101aa712830bc01)

M  +8    -0    libs/ui/widgets/KoFillConfigWidget.cpp

https://invent.kde.org/graphics/krita/commit/27a6d0eebce1c9fa29ddd023d5df898da01f27e6