Cloning the item into the previewe means that if we later increment
it, the preview clone doesn't update. Use the non-owning preview
interface to use the item directly in the preview.
Fixes: https://gitlab.com/kicad/code/kicad/-/issues/19433
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
The TOOL_EVENT constructor searches for ACTONS::cancelInteractive. That
action is global, so we need to ensure it is created before we try to
create these events - so switch to a create on first use paradigm for
the events.
This involves recasting the array tool from the slightly
eccentric ARRAY_CREATOR class into a full-blown TOOL, which
allows it to usefuly store state asd the dialog hides. This
is modelled on the POSITION_RELATIVE_TOOL strategy.
The by-radius-and-point mechanism is removed entirely,
as it's very fiddly and hard to describe in the UI,
and what you probably really want to do is get your
item onto the circle with tools like "move exact",
and then define the circle origin (now using the picker
tool)
Fixes: https://gitlab.com/kicad/code/kicad/-/issues/16783
Primary increment is the right most bit, secondary is the next
rightmost. So you can increment 'A1' to 'A2' or 'B1' with
Shift-Alt-Scroll and Ctrl-Alt-Scroll respectively.
Implemented as handling un-consumed scroll events that the
WX_VIEW_CONTROLS doesn't want because it has too many mods
set. Then dispatch these as TA_MOUSE_WHEEL events.
The default action from the selection tools is to run the
'increment' ACTION, which is implemented differently in the
various tools: eeschema can increment labels, symedit
does pin names and numbers, and fpedit does pad numbers.
These are context sensitive actions that increment "something"
about the selected item.
A generic 'increment' action can be produced, e.g. by other tools
or UI events, which has in increment step (positive or negative)
and an 'index' which determines what about the item should be
incremented - it's up to the increment action handler to decide
what that means.
And then add a primary and secondary inc/decrement action,
which allows to bind hotkeys to each.
Bind these to:
* Sym edit: increment pin names/number
increment text items
* Sch edit: increment lables and text
* FP/PCB: increment pin numbers
increment text items
This is useful when you want to copy text content out to some
external program (or put it in a text item/box).
I'm not sure it's possible to intuit exactly what a user wants,
as you will often want to copy items as the real items, and sometimes
as text. While KiCad might be able to make a smart guess, external
programs will have no chance!
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
Previously, it was flipped using the shape anchor position. But for this
shape, the anchor (top left corner)) is reinitialized after flipping, so
flipping twice moves the shape.
Now the rectangle center is used as reference position to flip the shape
Fixes https://gitlab.com/kicad/code/kicad/-/issues/18797
There was a gentle mish-mash of booleans, some with
true being left/right and some up/down, and some functions that
can flip in both axes (which is never actually done, and doesn't
really make geometric sense).
Replace all this with the FLIP_DIRECTION enum class, which makes
the intention completely unambiguous.
This also then allows a small scattering of simplifications,
because everything takes the same type and you don't have to
fiddle booleans to fit.
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.
Added Distance(VECTOR2) function that returns a double. Removed
superfluous EuclideanNorm, GetLineLength, integer constructor for
EDA_ANGLE (this promotes to double in the CTOR), DistanceLinePoint and
HitTestPoints
Also extended the size for arc calculations that get distances to center
points to avoid overflow
