Hm... Was this about creating assistants from shapes? If so:

WISHGROUP: Assistant kickstarter main project

*** Bug 343067 has been marked as a duplicate of this bug. ***

+1 for this feature

This needs some planning regarding which shapes and how they can be converted, but other than that, it is ready for implementation in my opinion.

Just for reference: my duplicate ticket was suggesting the ability to simply load vector images as assistants. Another option would be to let us use the existing vector drawing tools to draw on a vector layer and convert* that. I think both could be implemented simultaneously.

*What if we add a new layer type: assistant layer? For the most part, this would be a normal raster/vector layer that was given a flag and would live in a dedicated "assistant layers" docker to keep the normal layers docker clean. These layers would be hidden regardless of their per-layer visibility when "hide assistants" is enabled, otherwise could be toggled from there.

Actually, this assistant layers docker could also have an entry for regular assistants, to make it easy to find, select, show/hide them, and perhaps even group them in folders like normal layers. The new layer mentioned above could be called "Custom assistant" layer to set it apart from the built in ones.

I realize this wishlist goes all the way back to 2011, but I’d like to add some updated context and a potential lightweight bridge design for the “convert vector shapes into assistants” idea mentioned here and in the 2022 “Planned changes to assistants (F1)” thread.

The goal: allow existing vector paths to be used as live painting assistants that brushes can snap to. It’s a middle ground between vector and raster workflows, giving painters the precision of paths without losing the natural feel of the brush engine.

From reading the current codebase, a minimal bridge looks feasible between KoPathShape (from Flake) and KisPaintingAssistant (in libs/ui/toolutils/). Conceptually something like:

// pseudocode sketch class VectorTraceAssistant : public KisPaintingAssistant { public: VectorTraceAssistant(KoPathShape* source) { sourceShape = source; rebuildFromSource(); connect(source, &KoShape::transformationChanged, this, &VectorTraceAssistant::onSourceChanged); }

private: KoPathShape* sourceShape = nullptr; QVector<QPointF> cachedPolyline;

void rebuildFromSource() {
    auto t = sourceShape->absoluteTransformation();
    cachedPolyline.clear();
    for (auto seg : sourceShape->segments()) {
        cachedPolyline << seg->toPolyline(t); // flattened curve
    }
}

void onSourceChanged() {
    QTimer::singleShot(200, this, &VectorTraceAssistant::rebuildFromSource);
}

QPointF snap(const QPointF& p, const KisCoordinateConverter& converter) override {
    return findClosestPointOnPolyline(p, cachedPolyline);
}

};

Implementation notes:

Use KoShape::absoluteTransformation() to work in world coordinates.

Throttle updates with a small debounce (e.g. 200 ms) so complex shapes don’t bog the UI.

Add a “Link to Source” checkbox to freeze a static snapshot for performance or animation.

KisPaintingAssistantsDecoration already handles rendering and editing buttons, so integration could remain simple.


This effectively acts as a “digital stencil”: an editable, vector-defined guide that painters can trace with any brush. It doesn’t replace vector stroke editing but bridges the gap between vector precision and freehand painting.

I can gather recent references if useful:

Krita Artists “Planned changes to assistants (2022 or later)” thread (F1).

SVG-to-Painting-Assistant proof of concept script (2023).

“Vector layer convert to assistant lines layer” user discussion.


Adding this here just so future triage has more modern context and a possible direction for implementation. Thanks for keeping the assistant system evolving.