When routing and using layerNext (hotkey '+') to switch to next layer,
it will skip invisible layer, when click BUT_LEFT, the new line should
be in the same layer (visible layer)
Fixes https://gitlab.com/kicad/code/kicad/-/issues/14480
This commit partially reverts deb3cbf8. VIA and SOLID operator='s introduced in it do a good job but the cloning of holes in addHole() causes bogus collisions.
The diff-pair placer creates DIFF_PAIRs on the stack, which have
VIAs in them, which have HOLEs in them. The HOLEs get put in the
NODE's index, and we then crash later when doing a collision after
the stack variable has gone out of scope.
The stack variable is also copied while doing a search for "best",
and without the operator= definitions the "best" and the "original"
both think they own the HOLE.
Fixes https://gitlab.com/kicad/code/kicad/-/issues/14852
This was causing intermittent shove hiccups/freezes as RULE_RESOLVER::GetClearance() could return a bogus clearance value, taking
a cached value for an item that does not exist anymore. If the allocator/stack accidentally reclaimed such item's address - we were getting
very nasty and difficult to reproduce misbehaviours of the shove algorithm. Hopefully this patch fixes this. More info in the comments.
Note to self - I'm still not fully convinced I want PNS::ITEM pointers as the cache key, probably a unique counter would be better here.
The root cause was not removing the original (pre-dragging) via from the world, comparing the ITEM::Parent() pointers of the items was only hiding the main issue.
This also fixes the PNSViaCollisions test in the qa/ suite.
Don't open-code knockout text shape generation in several different
places.
Make sure triangulated knockout text gets clearance added when
specified.
Collapse duplicated footprint text item plot routine (they're no
longer any different from plotting pcb text items).
The previous test didn't handle is-self-tests between a hole and
its override in a different NODE. When calculating the pushout
force we don't remove the via (and its hole) from the current
node until after the calculation, so we end up checking for
collisions between the new (cloned) via's hole and the original
hole in the root node.
Fixes https://gitlab.com/kicad/code/kicad/-/issues/14795
Change teardrop generation to rely more heavily on BOARD_CONNECTIVITY
for improved performance.
Add updating of teardrops on BOARD_COMMIT::Push().
Also converts m_CopperItemRTreeCache to std::shared_ptr.
We don't copy it around anyway, and having to create a new set
of std::unique_ptr's for each operation is likely to be more
expensive than std::shared_ptr's overhead.
If you drag a track out and connect to a pad then press the hotkey
to switch the track posture it may not switch because the track
posture selected when the pad was reached is different than the one
that the mouse trail placer drew. As the aspect switching is done
in the mouse trail placer it does not know that the line placer
already override the track.
To correct this, in LINE_PLACER::FlipPosture() if the aspect is not
currently manually forced then copy the current aspect from the
line placer to m_mouseTrailPlacer before calling the FlipPosture()
method of m_mouseTrailPlacer. This will only be done once per
dragging session as once the aspect is manually forced it remains
manually forced. This seems to fix the issue with no undesirable
side effects.
Fixes: https://gitlab.com/kicad/code/kicad/-/issues/12369
About 1/3 of callers to Parent() don't care if they get the immediate
parent or not, about 1/3 want only the immediate parent, and about 1/3
want the hole parent's Parent().
I had earlier changed PNS::ITEM::HOLE to override Parent() and return
the hole parent's Parent(), but since the callers are pretty evenly
split I've reverted that and added BoardItem() for callers who want the
eventual BOARD_ITEM (whether a direct parent or a grandparent).
(Also removes a dead routine so I didn't have to figure out which of
the two it wanted....)
(While we don't currently have holes without a parent pad or via, you
could imagine using HOLEs in the future to represent a hole in a first-class
board outline, so better not to build this assumption in.)