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.
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.
Beziers can extend outside the control point hull,
and can also be far inside the hull. Especially the latter
interferes with selection.
So use the approximated segments to determine.
Adds the initial implementation of bezier overlay
(assistant) and geometry manager. This is only
implemented in Pcbnew - the code is common, but
eeschema doesn't currently use it for any shape.
Relates-To: https://gitlab.com/kicad/code/kicad/-/issues/8828
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.
We don't allow these to be set on the default netclass, so we
don't need to resolve it if they are missing in a custom netclass.
The renderer will use the colors specified in the application
color scheme.
This is useful if you want to give some preset options
to a user (e.g. recently used value) but stil have them
controlled and presented using the UNIT_BINDER logic.
Mostly intended right now for allowing testing of library tables
to help with testing chained loading, but it also decouples the
idea of a library table from on-disk files in general.
All current (real) lib table implementations continue to use the
file-based IO.
This could be made more general (not just for tables) if really
needed.
Probably this should be replaced with a less error-prone
approach. Right now the LSET -> BASE_SET system is risky
because it is converting a signed enum (PCB_LAYER_ID) to
a size_t in all the underlying operations.
Fixes https://gitlab.com/kicad/code/kicad/-/issues/18738
Before we edited the grid settings directly so cancel would keep your
changes.
Also includes numerous QoL improvements borrowed from Ian's patch,
and a few other small fixes.
ADDED: Add support in Pcbnew for exporting ODB++ files under Fabrication
Outputs, base on ODB++Design Format Specification (Release v8.1
Update 3 February 2021).
Note: There is still a lot of work to do if we will make the feature as
complete as the ODB++ spec. However, the current functionality's
completeness is already sufficient to cover general production
scenarios. I have compared the output results with Gerber files by
DFM tool and the accuracy at the graphic level should be able to
cover most usage scenarios. Additionally, I am very grateful to
the great open-source project Horizon EDA for giving me a lot of
inspiration in terms of ideas.
The feature can be enabled by adding "EnableODB=1" to the kicad_advanced
configuration file.
Fixes https://gitlab.com/kicad/code/kicad/-/issues/2019
This allows better value-semantics and const correctness.
This is a common method, as the Inflate method is
in-place:
BOX2I inflated = other;
// 'Inflated' is not inflated yet
inflated.Inflate( delta );
// Now it is inflated, but it's not const
This is annoying, as the 'inflated' box cannot easily
be made const. Instead:
const BOX2I inflated = other.GetInflated( delta );
When working near snap anchors, which come and go
rapidly, it's often useful to see what snaps have been
calculated. Add an advanced config to show these
(EnableSnapAnchorsDebug) on an overlay layer.
With more polish this could be a hotkey or something.
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.
Not only is this simpler, but it should be compatible
with all Boost versions (the cast is a problem in 1.86)
and it was also 'improved' in 1.86 for better mixing.
Fixes: https://gitlab.com/kicad/code/kicad/-/issues/18651
F_Cu = 0
B_Cu = 2
Remaining internal copper layers are even and incrementing
Non-copper layers are odd and incrementing.
This means that we can no longer do things like:
for( PCB_LAYER_ID layer = F_Cu; layer <= B_Cu; ++layer)
Instead, we have the class LAYER_RANGE:
for( PCB_LAYER_ID layer : LAYER_RANGE( F_Cu, B_Cu) )
Similarly, gt/lt tests should not refer to the integer value of the
layer. We have functions such as IsCopperLayer to test whether a layer
is copper or not.
When using the connectivity RTree, the third dimension is layer, so we
provide B_Cu with the special INT_MAX value, ensuring that elements
between F_Cu and B_Cu will be identified. There is a new, special
function GetBoardLayer() for interfacing with CN_ITEMS
Similarly, PNS layers remain unchanged and sequential. A set of
interface functions is provided to map PNS layers to Board layers and
back. This allows the PNS_LAYER_RANGE to function as expected
SHA256 is fine for one-offs but for large libraries where we might be
running the hash on hundreds of files, the speed difference is
appreciable. We don't require crytographic hashing, just a check that
the original file hasn't been corrupted so Murmur3 satisfies our basic
requirement.
