Change Details

This ticket's primary aim is to fix this ticket... https://bugs.kde.org/show_bug.cgi?id=404975 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 modified this to select none if the border size is set to 0. You also cannot select a "0" border width if you have a solid border selected. It will only go down to one 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.

This ticket's primary aim is to fix this ticket... https://bugs.kde.org/show_bug.cgi?id=404975 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.

This ticket's primary aim is to fix this ticket... https://bugs.kde.org/show_bug.cgi?id=404975 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 I also modified thise UI to select none"none" type if the border size is set to 0. You also cannot select a "0" border width if you have a solid border selected on the UI now. It will only go down to one1px 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.