Skip to content

Painting Assistant code cleanup and small fixes

Mathias Wein requested to merge (removed):assistant_fixes into master

Orignilally I just wanted to fix a few small annoyances that bugeed me for a while, but the code was quite a mess, and I also found unexpected issues, so it turned into quite a lot of code change already.

First the actual fixes:

  • 2 Point Perspective still ignored the moveThresholdPt parameter introduced with 98b08683 (a fix for bug 436422)
  • The moveThresholdPt also turned out the be calculated incorrectly, making it not constant in screen pixels but doubly affected by zoom.
  • "Plain" Perspective assistant ignored the snapToAny parameter, always behaving in single line mode. While the other mode is not particularly useful for freehand brush tool, I want to implement snapping for polyline tool, where this will be required.
  • The stroke start of many assistants was "sticky", that means the brush snapped to the stroke start whenever it came near again. While the fix for bug 436422 mitigated it, it was still there. Instead I rewrote the rather confusing and redundant KisPaintingAssistantsDecoration::adjustPosition() to stick at the stroke start only when required to make a decision.

I also increased the move threshold from 2 to 4 screen pixels, it was just too tricky for me to make it follow the right direction when the alternatives are not close to 90° apart, and I don't even have a 4k display...

And finally I moved code for getting the brush/cursor position to KisPaintingAssistant, it was scattered and repeated all over the place and often executed without even checking if it was required, and also the state variables where not properly encapsulated in the private data (there's still one left for the local area feature though).

Test Plan

Basically, try all kind of assistant combinations you can think of and check for regressions in snapping behavior.

Overall it shouldn't change except for the stroke start, which I hope behaves a bit better now. Especially zoom level should now not affect the behavior anymore.

Small artifacts at stroke begin are still possible unfortunately, fixing those would require quite a few changes in both tools and assistants.

Formalities Checklist

  • I confirmed this builds.
  • I confirmed Krita ran and the relevant functions work.
  • I tested the relevant unit tests and can confirm they are not broken. (If not possible, don't hesitate to ask for help!)
  • I made sure my commits build individually and have good descriptions as per KDE guidelines.
  • I made sure my code conforms to the standards set in the HACKING file.
  • I can confirm the code is licensed and attributed appropriately, and that unattributed code is mine, as per KDE Licensing Policy.

Reminder: the reviewer is responsible for merging the patch, this is to ensure at the least two people can build the patch. In case a patch breaks the build, both the author and the reviewer should be contacted to fix the build. If this is not possible, the commits shall be reverted, and a notification with the reasoning and any relevant logs shall be sent to the mailing list, kimageshop@kde.org.

Merge request reports