| Summary: | Really hard to choose color in Tool Options. | ||
|---|---|---|---|
| Product: | [Applications] krita | Reporter: | Dennis Fehr <cyraid> |
| Component: | Layers/Vector | Assignee: | Scott Petrovic <scottpetrovic> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | griffinvalley, scottpetrovic, tusooa |
| Priority: | NOR | Keywords: | triaged |
| Version: | 4.1.7 | ||
| Target Milestone: | --- | ||
| Platform: | Microsoft Windows | ||
| OS: | Microsoft Windows | ||
| Latest Commit: | https://invent.kde.org/kde/krita/commit/c2c5fdcca5bd3593c7699c06e3e5dacdee4a206f | Version Fixed In: | |
| Sentry Crash Report: | |||
|
Description
Dennis Fehr
2019-03-02 00:33:14 UTC
I cannot reproduce this here, does this also happen with the nightly builds? Yup. Even tried out the new nightly build as of today (March 8th). Remember, not the big color window that pops up.. So not the gradient color or anything, but the solid color option (not pattern, not gradient). Try the outline or the fill. I've found out this isn't just the color window, some sliders in the tool window will also jerk back.. So it's not just the color UI. Doesn't happen in main color selector area, or any other window it seems? Thanks for your comment! Automatically switching the status of this bug to REPORTED so that the KDE team knows that the bug is ready to get confirmed. In the future you may also do this yourself when providing needed information. Are you in a CMYK image by any chance? Because we know the selector doesn't quite work in CMYK. Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! Sorry I thought I responded to this already. Nope, in RGB mode. Thanks for your comment! Automatically switching the status of this bug to REPORTED so that the KDE team knows that the bug is ready to get confirmed. In the future you may also do this yourself when providing needed information. I can confirm this on Windows 10 git master. 1. Start a new document (default RGB8 sRGB ) 2. Create vector layer and make rectangle on the canvas 3. select the rectangle with the "Select shapes" tool and go to tool options 4. select the line tab 5. Select the color swatch to open the color picker 6. Click in the color triangle (don't drag) actual results: the color quickly reverts to what it was expected results: the color changes to where you clicked Can confirm this on 4.1.7 @ Ubuntu. It does not happen all the time, though. Sometimes it works fine, sometimes not. Git commit 217074f353bf7fc4f96ad281b091f05b14cd016e by Dmitry Kazakov. Committed on 20/04/2019 at 14:03. Pushed by dkazakov into branch 'master'. While trying to fix this, I noticed some of the cause of the "color fighting" was because of the large amount of signals that were being emitted and processed with the stroke and fill widgets for vector controls. I tried to help limit all these signals with a couple compressors on the fill and stroke config widgets. After adding those compressors, the state of the widgets were not updating right when changing selection. I then spent some time modifying the logic to get the tool options for the stroke and fill to update correctly. One thing to point out that I changed was how a "None" fill is calculated. Previously "None" was only calculated if a stroke object didn't exist (see the wrapper.type() ). I also modified the UI to select "none" type if the border size is set to 0. You cannot select a "0" border width if you have a solid border selected on the UI now. It will only go down to 1px now. The UI seemed to get in an odd state if you made a border 0px, then de-selected the object, then re-select it. Differential Revision: https://phabricator.kde.org/D20500 See merge request kde/krita!10 https://invent.kde.org/kde/krita/commit/217074f353bf7fc4f96ad281b091f05b14cd016e Git commit 217074f353bf7fc4f96ad281b091f05b14cd016e by Dmitry Kazakov. Committed on 20/04/2019 at 14:03. Pushed by dkazakov into branch 'master'. While trying to fix this, I noticed some of the cause of the "color fighting" was because of the large amount of signals that were being emitted and processed with the stroke and fill widgets for vector controls. I tried to help limit all these signals with a couple compressors on the fill and stroke config widgets. After adding those compressors, the state of the widgets were not updating right when changing selection. I then spent some time modifying the logic to get the tool options for the stroke and fill to update correctly. One thing to point out that I changed was how a "None" fill is calculated. Previously "None" was only calculated if a stroke object didn't exist (see the wrapper.type() ). I also modified the UI to select "none" type if the border size is set to 0. You cannot select a "0" border width if you have a solid border selected on the UI now. It will only go down to 1px now. The UI seemed to get in an odd state if you made a border 0px, then de-selected the object, then re-select it. Differential Revision: https://phabricator.kde.org/D20500 See merge request kde/krita!10 https://invent.kde.org/kde/krita/commit/217074f353bf7fc4f96ad281b091f05b14cd016e Git commit c2c5fdcca5bd3593c7699c06e3e5dacdee4a206f by Dmitry Kazakov, on behalf of Scott Petrovic. Committed on 20/04/2019 at 14:03. Pushed by dkazakov into branch 'master'. M +69 -8 libs/flake/KoShapeFillWrapper.cpp M +2 -0 libs/flake/KoShapeFillWrapper.h M +111 -64 libs/ui/widgets/KoFillConfigWidget.cpp M +6 -5 libs/ui/widgets/KoFillConfigWidget.h M +18 -12 libs/ui/widgets/KoStrokeConfigWidget.cpp https://invent.kde.org/kde/krita/commit/c2c5fdcca5bd3593c7699c06e3e5dacdee4a206f Git commit c472f2aa0a76bd2ffb43f1e1c58396dfc7bafedf by Dmitry Kazakov. Committed on 17/09/2019 at 12:17. Pushed by dkazakov into branch 'kazakov/vector-color-fix-381784'. Fix updating current shape color when undo/redo shapeChanged() is also called when the selection emits shapeContentChanged(), that is, when the list of shapes is still the same, but some properties of shapes are changed. In such a case we should still update the controls. The offending code was originally intended to fix bug 404975, but it seems like the bug doesn't happen anymore. M +0 -10 libs/ui/widgets/KoFillConfigWidget.cpp https://invent.kde.org/kde/krita/commit/c472f2aa0a76bd2ffb43f1e1c58396dfc7bafedf Git commit 3283661c87af12befbe51a190c899833f04f2c5f by Dmitry Kazakov. Committed on 21/09/2019 at 10:08. Pushed by dkazakov into branch 'krita/4.2'. Fix updating current shape color when undo/redo shapeChanged() is also called when the selection emits shapeContentChanged(), that is, when the list of shapes is still the same, but some properties of shapes are changed. In such a case we should still update the controls. The offending code was originally intended to fix bug 404975, but it seems like the bug doesn't happen anymore. M +0 -10 libs/ui/widgets/KoFillConfigWidget.cpp https://invent.kde.org/kde/krita/commit/3283661c87af12befbe51a190c899833f04f2c5f |