| Summary: | Vector Symbols and Vector shapes don't get the color i choose for them. | ||
|---|---|---|---|
| Product: | [Applications] krita | Reporter: | RamonMiranda <mirandagraphic> |
| Component: | Layers/Vector | Assignee: | 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: | ||
| 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
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. 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. 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. 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. 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. 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. > > A possibly relevant merge request was started @ https://invent.kde.org/graphics/krita/-/merge_requests/1491 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 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 Hi Ramon! Can you please try the Nightly from today to test if the problem is fixed? |