[krita] [Bug 404975] Really hard to choose color in Tool Options.

2019-09-21 Thread Dmitry Kazakov
https://bugs.kde.org/show_bug.cgi?id=404975

--- Comment #14 from Dmitry Kazakov  ---
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

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 404975] Really hard to choose color in Tool Options.

2019-09-17 Thread Dmitry Kazakov
https://bugs.kde.org/show_bug.cgi?id=404975

--- Comment #13 from Dmitry Kazakov  ---
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

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 404975] Really hard to choose color in Tool Options.

2019-04-20 Thread Dmitry Kazakov
https://bugs.kde.org/show_bug.cgi?id=404975

Dmitry Kazakov  changed:

   What|Removed |Added

  Latest Commit||https://invent.kde.org/kde/
   ||krita/commit/217074f353bf7f
   ||c4f96ad281b091f05b14cd016e
 Status|CONFIRMED   |RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from Dmitry Kazakov  ---
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

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 404975] Really hard to choose color in Tool Options.

2019-04-20 Thread Dmitry Kazakov
https://bugs.kde.org/show_bug.cgi?id=404975

Dmitry Kazakov  changed:

   What|Removed |Added

  Latest Commit||https://invent.kde.org/kde/
   ||krita/commit/217074f353bf7f
   ||c4f96ad281b091f05b14cd016e
 Status|CONFIRMED   |RESOLVED
 Resolution|--- |FIXED
  Latest Commit|https://invent.kde.org/kde/ |https://invent.kde.org/kde/
   |krita/commit/217074f353bf7f |krita/commit/c2c5fdcca5bd35
   |c4f96ad281b091f05b14cd016e  |93c7699c06e3e5dacdee4a206f

--- Comment #10 from Dmitry Kazakov  ---
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 from Dmitry Kazakov  ---
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 from Dmitry Kazakov  ---
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   -8libs/flake/KoShapeFillWrapper.cpp
M  +2-0libs/flake/KoShapeFillWrapper.h
M  +111  -64   libs/ui/widgets/KoFillConfigWidget.cpp
M  +6-5libs/ui/widgets/KoFillConfigWidget.h
M  +18   -12   libs/ui/widgets/KoStrokeConfigWidget.cpp

https://invent.kde.org/kde/krita/commit/c2c5fdcca5bd3593c7699c06e3e5dacdee4a206f

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 404975] Really hard to choose color in Tool Options.

2019-04-20 Thread Dmitry Kazakov
https://bugs.kde.org/show_bug.cgi?id=404975

Dmitry Kazakov  changed:

   What|Removed |Added

  Latest Commit||https://invent.kde.org/kde/
   ||krita/commit/217074f353bf7f
   ||c4f96ad281b091f05b14cd016e
 Status|CONFIRMED   |RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from Dmitry Kazakov  ---
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 from Dmitry Kazakov  ---
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

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 404975] Really hard to choose color in Tool Options.

2019-04-10 Thread bugzilla_noreply
https://bugs.kde.org/show_bug.cgi?id=404975

tus...@vista.aero changed:

   What|Removed |Added

 CC||tus...@vista.aero

--- Comment #9 from tus...@vista.aero ---
Can confirm this on 4.1.7 @ Ubuntu.
It does not happen all the time, though. Sometimes it works fine, sometimes
not.

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 404975] Really hard to choose color in Tool Options.

2019-04-09 Thread Scott Petrovic
https://bugs.kde.org/show_bug.cgi?id=404975

Scott Petrovic  changed:

   What|Removed |Added

   Assignee|krita-bugs-n...@kde.org |scottpetro...@gmail.com

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 404975] Really hard to choose color in Tool Options.

2019-04-05 Thread Scott Petrovic
https://bugs.kde.org/show_bug.cgi?id=404975

Scott Petrovic  changed:

   What|Removed |Added

 CC||scottpetro...@gmail.com
 Status|REPORTED|CONFIRMED
 Ever confirmed|0   |1

--- Comment #8 from Scott Petrovic  ---
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

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 404975] Really hard to choose color in Tool Options.

2019-03-29 Thread Bug Janitor Service
https://bugs.kde.org/show_bug.cgi?id=404975

Bug Janitor Service  changed:

   What|Removed |Added

 Status|NEEDSINFO   |REPORTED
 Resolution|WAITINGFORINFO  |---

--- Comment #7 from Bug Janitor Service  ---
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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 404975] Really hard to choose color in Tool Options.

2019-03-29 Thread Dennis Fehr
https://bugs.kde.org/show_bug.cgi?id=404975

--- Comment #6 from Dennis Fehr  ---
Sorry I thought I responded to this already. Nope, in RGB mode.

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 404975] Really hard to choose color in Tool Options.

2019-03-26 Thread Bug Janitor Service
https://bugs.kde.org/show_bug.cgi?id=404975

--- Comment #5 from Bug Janitor Service  ---
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!

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 404975] Really hard to choose color in Tool Options.

2019-03-12 Thread wolthera
https://bugs.kde.org/show_bug.cgi?id=404975

wolthera  changed:

   What|Removed |Added

 Status|REPORTED|NEEDSINFO
 Resolution|--- |WAITINGFORINFO

--- Comment #4 from wolthera  ---
Are you in a CMYK image by any chance? Because we know the selector doesn't
quite work in CMYK.

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 404975] Really hard to choose color in Tool Options.

2019-03-08 Thread Bug Janitor Service
https://bugs.kde.org/show_bug.cgi?id=404975

Bug Janitor Service  changed:

   What|Removed |Added

 Resolution|WAITINGFORINFO  |---
 Status|NEEDSINFO   |REPORTED

--- Comment #3 from Bug Janitor Service  ---
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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 404975] Really hard to choose color in Tool Options.

2019-03-08 Thread Dennis Fehr
https://bugs.kde.org/show_bug.cgi?id=404975

--- Comment #2 from Dennis Fehr  ---
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?

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 404975] Really hard to choose color in Tool Options.

2019-03-06 Thread wolthera
https://bugs.kde.org/show_bug.cgi?id=404975

wolthera  changed:

   What|Removed |Added

 Resolution|--- |WAITINGFORINFO
 CC||griffinval...@gmail.com
 Status|REPORTED|NEEDSINFO
   Keywords||triaged

--- Comment #1 from wolthera  ---
I cannot reproduce this here, does this also happen with the nightly builds?

-- 
You are receiving this mail because:
You are watching all bug changes.