Bug 399127 - Vector object fills itself when gradient stroke is selected in tool settings
Summary: Vector object fills itself when gradient stroke is selected in tool settings
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Applications
Component: Tools/Vector (show other bugs)
Version: nightly build (please specify the git hash!)
Platform: Microsoft Windows Microsoft Windows
: NOR normal
Target Milestone: ---
Assignee: Krita Bugs
URL:
Keywords:
: 403876 (view as bug list)
Depends on:
Blocks:
 
Reported: 2018-09-27 06:03 UTC by acc4commissions
Modified: 2021-06-08 07:28 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
(Video example) (690.12 KB, video/mp4)
2018-10-18 23:08 UTC, mvowada
Details
(correct video example) (827.33 KB, video/mp4)
2018-10-18 23:13 UTC, mvowada
Details

Note You need to log in before you can comment on or make changes to this bug.
Description acc4commissions 2018-09-27 06:03:33 UTC
git 6e7ebf3


STEPS TO REPRODUCE
1. Draw an object in vector layer
2. Select the gradient fill option on stroke in tool settings

OBSERVED RESULT
color filled object

EXPECTED RESULT
Just an empty object surrounded by a gradient line

ADDITIONAL INFORMATION

Windows 7
Comment 1 Halla Rempt 2018-09-27 07:24:14 UTC
I can reproduce this, but only if I select the radial option for the gradient in the stroke tab.
Comment 2 acc4commissions 2018-10-16 06:31:13 UTC
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.
Comment 3 mvowada 2018-10-18 23:08:00 UTC
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.
Comment 4 mvowada 2018-10-18 23:13:23 UTC
Created attachment 115742 [details]
(correct video example)
Comment 5 Tiar 2019-02-03 12:36:09 UTC
*** Bug 403876 has been marked as a duplicate of this bug. ***
Comment 6 Scott Petrovic 2019-04-22 20:58:04 UTC
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.
Comment 7 acc4commissions 2019-04-23 10:08:48 UTC
(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.
Comment 8 Scott Petrovic 2019-04-23 12:03:15 UTC
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
Comment 9 Scott Petrovic 2019-04-25 13:30:36 UTC
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
Comment 10 vanyossi 2020-05-30 00:44:39 UTC
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.
Comment 11 Bug Janitor Service 2021-03-31 22:17:33 UTC
A possibly relevant merge request was started @ https://invent.kde.org/graphics/krita/-/merge_requests/784
Comment 12 Dmitry Kazakov 2021-04-01 05:49:26 UTC
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
Comment 13 sh_zam 2021-06-08 07:22:05 UTC
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
Comment 14 sh_zam 2021-06-08 07:28:48 UTC
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