Bug 404975 - Really hard to choose color in Tool Options.
Summary: Really hard to choose color in Tool Options.
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Applications
Component: Layers/Vector (show other bugs)
Version: 4.1.7
Platform: Microsoft Windows Microsoft Windows
: NOR normal
Target Milestone: ---
Assignee: Scott Petrovic
URL:
Keywords: triaged
Depends on:
Blocks:
 
Reported: 2019-03-02 00:33 UTC by Dennis Fehr
Modified: 2019-09-21 12:09 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dennis Fehr 2019-03-02 00:33:14 UTC
SUMMARY
Really hard to choose color in Tool Options.

STEPS TO REPRODUCE
1. Make a vector layer.
2. Make an object.
3. Go to tool options and select solid color.
4. Click the color to be able to choose.

OBSERVED RESULT

When clicking in the color triangle, it always seems to 'jump back' to what it was previously. You have to hold in the mouse and it will "sometimes" select the color.

EXPECTED RESULT

Select the color with ease. This would be nice if you just used the main color window where you can select the RGB yourself. That triangle color picker window works (for example, the "Select a color" window that opens when you select your primary / secondary color).

SOFTWARE/OS VERSIONS
Windows 10

ADDITIONAL INFORMATION
I've noticed the UI a lot slower than I remember, too.. Maybe I'm just used to the Linux version (used to use Linux).
Comment 1 wolthera 2019-03-06 09:08:02 UTC
I cannot reproduce this here, does this also happen with the nightly builds?
Comment 2 Dennis Fehr 2019-03-09 03:32:35 UTC
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?
Comment 3 Bug Janitor Service 2019-03-09 04:33:09 UTC
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.
Comment 4 wolthera 2019-03-12 15:18:27 UTC
Are you in a CMYK image by any chance? Because we know the selector doesn't quite work in CMYK.
Comment 5 Bug Janitor Service 2019-03-27 04:33:20 UTC
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!
Comment 6 Dennis Fehr 2019-03-29 11:21:22 UTC
Sorry I thought I responded to this already. Nope, in RGB mode.
Comment 7 Bug Janitor Service 2019-03-30 04:33:11 UTC
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.
Comment 8 Scott Petrovic 2019-04-05 15:17:02 UTC
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
Comment 9 tusooa 2019-04-10 15:55:00 UTC
Can confirm this on 4.1.7 @ Ubuntu.
It does not happen all the time, though. Sometimes it works fine, sometimes not.
Comment 10 Dmitry Kazakov 2019-04-20 14:03:49 UTC
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
Comment 11 Dmitry Kazakov 2019-04-20 14:03:50 UTC
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
Comment 12 Dmitry Kazakov 2019-04-20 14:03:50 UTC
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
Comment 13 Dmitry Kazakov 2019-09-17 12:21:48 UTC
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
Comment 14 Dmitry Kazakov 2019-09-21 12:09:08 UTC
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