Skip to content

Text: Remove KoSvgTextChunkShape and replace it with a KisForest of KoSvgTextContentElements.

Wolthera van Hövell requested to merge woltherav/krita:text-tool-phase-2-kis-forest-refactor into master

As discussed, this replaces the internal text data representation of KoSvgTextChunkShape: public KoShape with a KisForest<KoSvgTextContentElement>, this will make it simpler to edit the rich text data (Without this, we'd have to be really careful about not leaking KoSvgTextChunkShapes when editing).

I tried to keep the refactor to a minimum. The only real differences outside the internal structure changes are that Fill and Stroke, in addition to a few other common SVG properties are now stored inside the TextProperties.

Of note regarding using KisForest:

  • When the kisforest is empty it is easy for the textshape to be invalid, but the kisforest does need to be empty to allow parsing to work properly.
  • while siblingCurrent(child_it) works, siblingEnd(child_it) and siblingBegin(child_it) rely on child_it to be a valid node, so you can't do:
KisForest<T> tree;
KisForest<T>child_iterator child = tree.childEnd();
tree->insert(siblingEnd(child), T);

and instead need to do:

KisForest<T> tree;
KisForest<T>child_iterator child = tree.childEnd();
tree->insert(childEnd(parent(child)), T);
  • Similarly, there's a constness issue which made cloning the KoSvgTextShape::Private annoying.

Test Plan

Test any Krita file with text shapes.

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