so, I added a scetch for it's interface.

As Woltherav noticed earlier, this will require rework of assistant tool's code (and therefore assistants'), because in current implementation assistants can only be controlled by moving points (handles) and little moving-switching-on-and-off-and-moving control.

Also, the same GUI will work with any other projection type (if is doesn't have parameters to it).

I want to write the code for this assistant, but I'm not sure if I'm right person to singlehandedly decide new architecture of assistant tool and assistants (At least I would need to talk to other developers).

also, you can find maths on almost all projections in this dir on github's blinky repo:
https://github.com/shaunlebron/blinky/blob/master/game/lua-scripts/lenses/ (in lenses equations you can see usage functions "latlon_to_ray" and "ray_to_latlon". they are defined here)

Well, I am the previous/last person to extend the assistants so by that logic I am the maintainer of those files :D

My suggestion is that we start to make a list of what we need the assistants to do and start designing from there. There's quite a few variables from that. Similarly, we'll need to look at what is already there and how the different parts interact.

In what timezone are you?

Overview of the most important current classes:

RulerAssistantTool: adds the assistant factories to the registry
KisRulerAssistantTool: manipulates the assistants
KisPaintingAssistantsDecoration: owns all assistants for a canvas
KisPaintingAssistantManager: manages the assistants for a view/canvas
KisDocument: owns a set of KisPaintingAssistants
KisPaintingAssistant: one assistant, subclassed for every kind of assistant
KisPaintingAssistantHandle: the primary way to change assistants

Note: we also want to add a second kind of thing, reference images, that can be laid out around and over the image and from which colors can be picked. There is a huge amount of overlap in what is needed for both these concepts.

Requirements

• toggle key/button for snapping
• different kinds of widgets that can be saved, loaded and distinguished visually
  • nodes that define the location of the assistant
  • nodes that define the state of the assistant
• Option: on crop/transform/mirror canvas/scale: assistants should be processed, too
• Transform operations on assistants independent of image transform; working on a selection of assistants
• Integrate clone tool with assistants

Painting assistants are for:

• Construct a complex image without using actual pixels (complex perspective construction)
• Help guide the hand while painting (draw many parallel lines, concentric circles)

Organizing assistants:

• In groups, in a hierarchy, with groups being visible or not, magnetic or not
• Associated with one or more layers or layer groups