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.
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.
This makes it clearer that it is a polyfill-type affair
and make it easier to swap for the std:: one when the
compiler support is guaranteed.
Also avoid double underscores in parameter names,
as well as underscore-capital latter as they are reserved.
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
- Fix incorrect values of displayed layers of blind/buried vias
- Fix possible incorrect layer order in PCB_VIA::SanitizeLayers()
- fix some display issues in 3D viewer.
- fix issue in LAYER_RANGE::Contains(): sometimes the test was incorrect.
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.
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.
Adds REPORTER::HasMessageOfSeverity for WX_STRING_REPORTER,
which allows us to show simulation warnings and fail only if there's errors.
Also fixes a crash when SPICE_GENERATOR_KIBIS throws an IO_ERROR.
Fixes https://gitlab.com/kicad/code/kicad/-/issues/18143
When the italic or bold nature is changed, text using outline fonts may
need to change its font. Add this to the SetItalic/SetBold functions.
Also add a counterpart SetItalicFlag function (following SetBoldFlag)
when you only need to set the flag (e.g. when importing or changing
everything in the text properties dialog).
Fixes: https://gitlab.com/kicad/code/kicad/-/issues/18592
This allows to see what the current snap point is, which is useful when
zoomed in, or the point is like the corner of a rounded pad where it's
"in free space" and might not be immediately obvious.
First, ensure that we calculate the bbox of the imported elements.
If the total BBOX is outside our allowed value, refused to import. This
needs to be scaled or addressed in an external editor
If the bbox fits, then make sure that we clamp it such that the largest
element is still within our bounds
Fixes https://gitlab.com/kicad/code/kicad/-/issues/18523
jean-pierre charras
John Beard
Mike Williams
Alex Shvartzkop
Jon Evans
Seth Hillbrand
Eric
Marek Roszko
Jeff Young