Saving the best for last - the one that wound me up enough to
start this process - textboxes, which sometimes, but not always
behave like rectangles.
Rather than some exciting multiple inheritance of
RECTANGLE_POINT_EDIT_BEHAVIOR and a hypothetical rotated
rectangle behavior, delegate the rectangular behavior to
static helpers in the rectangle one.
They still can't be edited when rotated, but at least now there
is some hope that it's tractable!
Especially the aligned dims are fiddly, but all the
dimensions need the array size to be carefully kept
controlled, which is now part of the invariant of
each behavior.
This also changes the interface on the GENERATOR classes
to no longer take a shared_ptr - these methods are synchronous
and don't store (shared) ownership of the EDIT_POINTs.
This is a pretty straightforward one
(though there was a latent bug here because both CIRCLE
and ARC used CIRC_CENTER for the constrainer. If an ARC
and CIRCLE center were not the same index (and nothing says they
have to be) that could be wrong or crash.
This is a good example of an edit behaviour that had a lot
of code in PCB_POINT_EDITOR that was only used for a single
item type. Many of these (now static) functions will probably
find use in other places arcs crop up like filleted shapes
and also in eeschema.
But for now, keep it simpler and keep them near where they
are used.
This introduces the POINT_EDITOR_BEHAVIOR class, which
allows a "behavior" to be defined, which covers the creation
of edit points, updating the points on edit, and pushing the
edited points back into the object.
This keeps the logic for a single item "type" (e.g. a SEGMENT
or TEXTBOX, etc) in one place, rather than fragmneted throughout
the POINT_EDITOR class, where the invariants like point count
are difficult to keep track of as the TOOL progresses.
For now, it's implemented as an optional class, just for SEGMENT
and other tpyes work as before. Adding new types is then a
"pin-compatible" drop-in process.
When in rectangle mode, it still needs to act like a rectangle, but
it doesn't go through the usual PCB_SHAPE handler (even though it is
a PCB_SHAPE too).
Come up with a plausible default chamfer size, rather
than prompting every time with a modal (and then you have
to handle when the chanfer doesn't fit). This could be
changed if it's more annoying this way. But if we had
proper edge-dragging in zones, probably would be better
than setting a chanfer manually.
Also fix the GetNeighbourIndexes which seems to have
always been broken (but is not actually used by anything at
present).
Relates-To: https://gitlab.com/kicad/code/kicad/-/issues/16771
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
Break the non-PCB-specfic parts of PCB_REFERENCE_IMAGE out
to a common REFERENCE_IMAGE class, which is then composed into
the PCB_REFERENCE_IMAGE. This will make it easier to bring the
transform origin logic to eeschema without repetition.
This is stored as an offset from the image position,
which is the centre of the image. When interactively edited, the
transform origin stays in place. This makes it easier to scale an image
around some fixed feature in the image.
For now this is not saved out to the format, so it
reinitialises to (0, 0) each time. This means scale around
the midpoint, which is the current behaviour.
Some shapes, like arcs and beziers have "lines" that
can be useful to see when editing, but aren't directly
editable and may not overlap the object's own lines.
So make it possible to, indepedently:
- Turn off the centre-point drag handle affordance
- Show the actual line segment on screen.
This is a pretty major rework of the snapping system.
The GRID_HELPERs now have a separate CONSTRUCTION_MANAGER
which handles some of the state involving "construction
geometry".
This is fed with 'extended' geometry (e.g. "infinite" lines from
segments) for use in generating things like intersection points.
It also handles adding this geoemtry to a GAL view item
(CONSTRUCTION_GEOM) for display to the user.
The process is:
* A TOOL creates a GRID_HELPER
* Optionally, it pre-loads a "persistent" batch of construction
geometry (e.g. for an item's original position)
* The grid helper finds useful snap 'anchors' as before, including
those involving the construction items.
* Other items on the board can be 'activated' by snapping to one
of their main points. Then, if it has construction geometry,
it will be added to the display. At most 2 items of this kind of
geometry are shown, plus the original item, to reduce avoid
too much clutter.
The dashed snap lines state machine is also handled in the
CONSTRUCTION_MANAGER and displayed in the CONSTRUCTION_GEOM item.
Put these in a separate header - they don't need to be available
whenever VECTOR2 is, but they are generic, reusable functions that
can have the corner cases defined and tested.
This is quite fiddly to do in a way that doesn't have wierd
effects, and is shared between ALIGNED and ORTHOGONAL dimensions,
so break it out to a little helper class that handles the
stored state and fiddling with the geometry.
Add direct handling of quadratic beziers to save compute time and number
of points. Update cubic interpolation to reduce number of points
generated for a given smoothness
Cache data on open and used cached data to avoid multiple re-calcs
Remove minimum line length and number of segments and replace with
standard max error level. Allows us to specify the tolerance of bezier
interpolation
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
The router preview item can be specific to the part that is being
tuned, rather than the whole net. It's also less visually noisy as
it doesn't dim/undim the rest of the board.
Using kigfx preview items for the status keeps us from having a bunch
of focus issues with the status popup window.
