By dereferencing first, we force a get() on the optional and try to pass
that to a routine that takes an optional parameter. Just passing the
optional reference protects against accessing an invalid
Fixes https://gitlab.com/kicad/code/kicad/-/issues/20934
(cherry picked from commit 6c09957799)
Recommendation is to avoid using the year nomenclature as this
information is already encoded in the git repo. Avoids needing to
repeatly update.
Also updates AUTHORS.txt from current repo with contributor names
CHANGED: PCB file format now supports saving/loading complex padstacks
CHANGED: PTH pads are now rendered per copper layer in the copper color;
the PTH pad color is no longer used.
ADDED: support for importing complex pad stacks from Altium PCBs
Enforce padstack-aware access to pad properties across KiCad
Fixes https://gitlab.com/kicad/code/kicad/-/issues/8182
Don't enforce that every merge result has to be
non-disjoint. Sometimes it will merge in the end
when gaps are filled in by other shapes. Even if
not, at the end, just create a new polygon for
each disjoint polygon.
This is a little bit like the bounding hull tool, but the
output is "exact" and it only supports the most common
source items.
By 'exact', this means that rounded corners are real arc
segments rather than polygonal approximations. Obviously,
this is rather tricky in the general case, and especially
for any concave shape or anything with a bezier in it.
Envisioned main uses:
* Creating courtyard and silkscreen offsets in footprints
* Making slots around line or arcs.
The one thing that it does not currently do, but which it might
plausibly do without reimplementing Clipper is convex polygons,
which would bring trapezoidal pad outsets for free. But that
is a stretch goal, and bounding hull can be used.
This allows common operations like merging a pin courtyard
into the body courtyard in the fooprint editor, taking a
"bite" out of a polygon and so on,
For now, this only supports polygons made of straight lines.
There are some wierd cases when the operations result in nothing
(e.g. wen a big polygon is substracted from a smaller one that
it contains entirely). I have tried to do something senisble in
these cases, but there may be more optimal ways to handle it.
Relates-To: https://gitlab.com/kicad/code/kicad/-/issues/13025
This needs the ITEM_MODIFICATION_ROUTINE to learn to delete items.
Condense the item change handlers into a single injected object
(ITEM_MODIFICATION_ROUTINE::CHANGE_HANDLER) and provide the basic
implementation that just takes some callables.
This simplifies the construction of the routines and also would make
a CHANGE_HANDLER object possible that can be reused between different
tools.
Using the new ITEM_MODIFICATION_ROUTINE system, drop in two new
tools: chamfer and line extend. These are two geometric operations
that are relatively common when editing footprints in particular.
Chamfer delegates the geometric calculations to a dedicated unit
in kimath/geometry.
Describe the actions of the fillet tools is a generic way, so that the
same general pattern can be used for other tools that modify shapes on
the BOARD.
Basically, an "ITEM_MODIFICATION_ROUTINE" is defined, which is
configured and called multiple times, calling back to the EDIT_TOOL when
it modifies or creates an item.
The motivation here is to make it easier to slot in new line-based
tools like chamfer, extend and so on without having to redo the
complicated item, selection and commit handling each time, and keep the
core "routines" simple and decoupled from the EDIT_TOOL's
internals.
This also resolves#15094 because the new commit handling does the right
thing when items were "conjured up" for the fillet (e.g. when a
rectangle is decomposed into lines).
Fixes: #15094
John Beard