Bug 453331

Summary: Vector Symbols and Vector shapes don't get the color i choose for them.
Product: [Applications] krita Reporter: RamonMiranda <mirandagraphic>
Component: Layers/VectorAssignee: Krita Bugs <krita-bugs-null>
Status: REPORTED ---    
Severity: normal CC: ahab.greybeard, halla, shzam
Priority: NOR Keywords: triaged
Version: 5.0.6   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: The Symbol library to make some tests.
attachment-22670-0.html
attachment-1124-0.html
attachment-6340-0.html

Description RamonMiranda 2022-05-03 08:58:58 UTC
Created attachment 148531 [details]
The Symbol library to make some tests.

STEPS TO REPRODUCE
VIDEO: https://drive.google.com/file/d/1V5PMUuyeInDjwZ1n71Jdqe-H7zdEHA7T/view?usp=sharing
1. Create a new image. 
2. Create a vector layer (Shift+ins)
3. Draw a Square shape and try to change the color.
4. Create another vector layer
5. Drag a symbol from the vector library. ( I link the file used).
6. Ungroup  with right click over the selected symbol. and look the color that appears in tool options for vector.
7. Try to change the color.

OBSERVED RESULT
The color selected is not exact or goes to black or pure saturation

EXPECTED RESULT
The selected color in tool options fill parameter is used or the color is selected from the color wheel when the symbol (ungrouped) is selected. (It could be interesting and useful to detect if it is single shape and can be colorized directly or is a group of shapes and you have to ungroup. Faster use of symbols)

SOFTWARE/OS VERSIONS
Windows: Windows 10 Works OK with Krita 5.0.2
macOS: 
Linux/KDE Plasma: Kubuntu 20.04
(available in About System)
KDE Plasma Version: 5.18.8
KDE Frameworks Version: 5.68.0
Qt Version: 5.12.8
OS Information 64 bit

  Build ABI: x86_64-little_endian-lp64
  Build CPU: x86_64
  CPU: x86_64
  Kernel Type: linux
  Kernel Version: 5.4.0-109-generic
  Pretty Productname: Ubuntu 20.04.4 LTS
  Product Type: ubuntu
  Product Version: 20.04
  Desktop: KDE

ADDITIONAL INFORMATION
VIDEO: https://drive.google.com/file/d/1V5PMUuyeInDjwZ1n71Jdqe-H7zdEHA7T/view?usp=sharing
Comment 1 Ahab Greybeard 2022-05-04 15:54:32 UTC
With the 5.0.6 appimage on Debian 10:

For Steps 1,2,3, I have no problem changing the fill colour using the Tool Options docker or the Advanced Colour Selector docker.

For Step 5,6,7, you can't change the colour until it's Ungrouped (as expected) and then I have no problem using the Tool Options docker or the Advanced Colour Selector docker.

I have no idea why you have the problems that are shown on your attached video.

Whatever the content of the Vector Library item, an additional level of grouping is applied when it's dragged onto the image.
I believe this is to take account of the situation where a vector item is made of a collection of ungrouped elements so that these can be drag/moved around the canvas and not be separated.
Comment 2 RamonMiranda 2022-05-04 20:08:42 UTC
Created attachment 148563 [details]
attachment-22670-0.html

Thanks for the feedback, i feel is a weird bug. If it can't be replicated
easily then i don't know how to give more info :S
anyway, Thanks Ahab for your time testing the bug.

El mié, 4 may 2022 a las 17:54, Ahab Greybeard (<bugzilla_noreply@kde.org>)
escribió:

> https://bugs.kde.org/show_bug.cgi?id=453331
>
> Ahab Greybeard <ahab.greybeard@hotmail.co.uk> changed:
>
>            What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>                  CC|
> |ahab.greybeard@hotmail.co.u
>                    |                            |k
>
> --- Comment #1 from Ahab Greybeard <ahab.greybeard@hotmail.co.uk> ---
> With the 5.0.6 appimage on Debian 10:
>
> For Steps 1,2,3, I have no problem changing the fill colour using the Tool
> Options docker or the Advanced Colour Selector docker.
>
> For Step 5,6,7, you can't change the colour until it's Ungrouped (as
> expected)
> and then I have no problem using the Tool Options docker or the Advanced
> Colour
> Selector docker.
>
> I have no idea why you have the problems that are shown on your attached
> video.
>
> Whatever the content of the Vector Library item, an additional level of
> grouping is applied when it's dragged onto the image.
> I believe this is to take account of the situation where a vector item is
> made
> of a collection of ungrouped elements so that these can be drag/moved
> around
> the canvas and not be separated.
>
> --
> You are receiving this mail because:
> You reported the bug.
Comment 3 sh_zam 2022-05-10 08:49:31 UTC
Hi Ramon!

I can't reproduce the color change bug :( But I wonder if you can reproduce this bug: https://bugs.kde.org/show_bug.cgi?id=449606. The code for them is sort of interconnected.
Comment 4 Halla Rempt 2022-05-10 13:06:16 UTC
I also cannot reproduce this, though weirdly enough, resizing the symbols from this library is really weird, the symbol gets translated when resizing, and dragging on top to make a symbol taller makes it smaller.
Comment 5 RamonMiranda 2022-05-10 13:15:41 UTC
Created attachment 148706 [details]
attachment-1124-0.html

I have updated the libraries, Halla. Let me know if they work for you. Here
they are working ok.
 Only one thing is that when I drag the symbol to the canvas, the symbol is
a bit small. How can I control the size of the Symbol? Also I have noticed
that modifying the pivot point in the layer can affect the transformation.
But if you drag the symbol to a new vector layer, everything works ok.
I notice that I look a lot for the "duplicate" option when I use symbols.
It would be interesting to be considered as an addition with time.

Nature:
https://drive.google.com/file/d/1EaCpusrwjlcndtiYtBXGRx_xD7gCD_GN/view?usp=sharing
Sci-fi:
https://drive.google.com/file/d/11glCDHvY_C0ypcQ6EVLbCeqkxlHqJdkN/view?usp=sharing

Sh_zam: I will test the things you are referring to. Thanks.
 @everybody i know this bug is weird, so do your best with time. ;)


El mar, 10 may 2022 a las 15:06, Halla Rempt (<bugzilla_noreply@kde.org>)
escribió:

> https://bugs.kde.org/show_bug.cgi?id=453331
>
> Halla Rempt <halla@valdyas.org> changed:
>
>            What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>                  CC|                            |halla@valdyas.org
>            Keywords|                            |triaged
>
> --- Comment #4 from Halla Rempt <halla@valdyas.org> ---
> I also cannot reproduce this, though weirdly enough, resizing the symbols
> from
> this library is really weird, the symbol gets translated when resizing, and
> dragging on top to make a symbol taller makes it smaller.
>
> --
> You are receiving this mail because:
> You reported the bug.
Comment 6 RamonMiranda 2022-05-10 13:56:40 UTC
Created attachment 148708 [details]
attachment-6340-0.html

Sz_zam: I have tested the issue with gradients and in Linux I get these
behaviors.
I can translate the gradient, scale, change the angle or flip.
I can modify each stop without problems.
I can edit the stops with the menu.
I can select each stop with mouse cursor or arrow buttons.
Weird, because gradients work ok in Kubuntu 20.04 on my laptop. The solid
colors work better in Windows 10. :S

El mar, 10 may 2022 a las 15:15, Ramón Miranda (<mirandagraphic@gmail.com>)
escribió:

> I have updated the libraries, Halla. Let me know if they work for you.
> Here they are working ok.
>  Only one thing is that when I drag the symbol to the canvas, the symbol
> is a bit small. How can I control the size of the Symbol? Also I have
> noticed that modifying the pivot point in the layer can affect the
> transformation. But if you drag the symbol to a new vector layer,
> everything works ok.
> I notice that I look a lot for the "duplicate" option when I use symbols.
> It would be interesting to be considered as an addition with time.
>
> Nature:
> https://drive.google.com/file/d/1EaCpusrwjlcndtiYtBXGRx_xD7gCD_GN/view?usp=sharing
> Sci-fi:
> https://drive.google.com/file/d/11glCDHvY_C0ypcQ6EVLbCeqkxlHqJdkN/view?usp=sharing
>
> Sh_zam: I will test the things you are referring to. Thanks.
>  @everybody i know this bug is weird, so do your best with time. ;)
>
>
> El mar, 10 may 2022 a las 15:06, Halla Rempt (<bugzilla_noreply@kde.org>)
> escribió:
>
>> https://bugs.kde.org/show_bug.cgi?id=453331
>>
>> Halla Rempt <halla@valdyas.org> changed:
>>
>>            What    |Removed                     |Added
>>
>> ----------------------------------------------------------------------------
>>                  CC|                            |halla@valdyas.org
>>            Keywords|                            |triaged
>>
>> --- Comment #4 from Halla Rempt <halla@valdyas.org> ---
>> I also cannot reproduce this, though weirdly enough, resizing the symbols
>> from
>> this library is really weird, the symbol gets translated when resizing,
>> and
>> dragging on top to make a symbol taller makes it smaller.
>>
>> --
>> You are receiving this mail because:
>> You reported the bug.
>
>
Comment 7 Bug Janitor Service 2022-06-27 11:30:01 UTC
A possibly relevant merge request was started @ https://invent.kde.org/graphics/krita/-/merge_requests/1491
Comment 8 amyspark 2022-06-28 19:50:29 UTC
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 455794, bug 447464, bug 449606

M  +2    -20   libs/ui/widgets/KoFillConfigWidget.cpp

https://invent.kde.org/graphics/krita/commit/fc362afcb2954d10f8391f803b44a4c2ac88de39
Comment 9 amyspark 2022-06-28 19:52:45 UTC
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 455794, bug 447464, bug 449606
(cherry picked from commit fc362afcb2954d10f8391f803b44a4c2ac88de39)

M  +2    -20   libs/ui/widgets/KoFillConfigWidget.cpp

https://invent.kde.org/graphics/krita/commit/de938cfc89875c360a0e161b5de723739eedf2cc
Comment 10 sh_zam 2022-06-29 17:38:05 UTC
Hi Ramon!

Can you please try the Nightly from today to test if the problem is fixed?