Tracking Issue: Improving editing support for vector meshes

[4adex]

This issue tracks existing bugs related to the Pen Tool and Path Tool when working with vector meshes, especially in scenarios where an anchor point is connected to more than two segments. Many existing features assume that anchors are only shared by at most two segments, which breaks certain behaviours when this assumption is violated.

• Pressing C while dragging a handle from an anchor point does not work well when more than two segments are connected to the corresponding anchor. (For both path tool and pen tool). (Fix vector mesh editing behavior in various edge cases #2943)
• Alt + drag while a handle is selected makes the other handle “colinear and equidistant”, this behaviour needs to be configured keeping multiple handles in mind. (Fix vector mesh editing behavior in various edge cases #2943)
• Tab press while dragging an handle swaps to other handle (this should only happen if two handles are in opposite of one another and with G1 continuity enabled) (Fix vector mesh editing behavior in various edge cases #2943)
• Currently deleting an anchor adds a segment which connects the path but without the anchor point. This should not happen if the anchor is connected to more than two segments.
• Colinear Handles toggle should be disabled when the corresponding anchor has more than 2 segments connected. (Fix vector mesh editing behavior in various edge cases #2943)
• If a new segment is started from an intermediate anchor (an anchor which is connected to exactly two segments), the corresponding handle at start has G1 continuity enabled, which leads to unwanted handle movements in other segments. (cannot reproduce now, most probably it has already been corrected)

[Keavon]

Currently deleting an anchor adds a segment which connects the path but without the anchor point. This should not happen if the anchor is connected to more than two segments.

It would actually be best to have any pair of colinear segments have those segments be joined/reconnected, while others are deleted. So in this example, which has two colinear pairs:

Instead of deletion producing:

It would produce:

[4adex]

#2695 (comment)
This will require changing some core logic of deletion, this I can do after #2768 is completed and merged.
Should we make this a new issue instead to keep track?

[Keavon]

It doesn't have to re-fit to do what I described in my screenshots above.

[4adex]

Yes but I have rewritten the major part of the deletion logic in #2768, so if both are worked upon in parallel, there will be conflicts. Hence I suggested that this can be worked after #2768 is completed.