https://bugs.kde.org/show_bug.cgi?id=404975
Dmitry Kazakov <dimul...@gmail.com> 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 <dimul...@gmail.com> ---
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.
