When an arc has a very small curvature, we should not waste time with
the arc collision mode and instead just use the segment collision as it
is effectively the same result
Fixes https://gitlab.com/kicad/code/kicad/-/issues/19422
By adding points to holes as we go, we leave ourselves open
to adding invalid (<3 point) holes to the polygons. This causes
crashes if it happens, so we should never allow it to happen.
Instead of building holes in-place, construct them externally
and only add them if they are valid.
This probably wouldn't actually happen for a valid Fabmaster
file, but if it did, it would be bad new, and we shouldn't leave
crashable pathways facing user input.
Remove option "use Clipper1" (now outdated) on all platforms.
Use of advanced config created the issue, so it is just disabled on msys2.
Should not change anything on other platforms.
If we are checking a point that is inline with multiple segments, we
were counting both the entry and exit as crossings, leading to points
inside a polygon being registered as outside. Changing the conditional
to only catch one crossing as required.
Adds a QA check to ensure that this remains fixed
Fixes https://gitlab.com/kicad/code/kicad/-/issues/18377
It looks like the new variant (with aMaxError) behaves in a subtly different way, resulting in router hiccups.
This needs more in-depth investigation, but for the moment, the older function does the job.
In some situations then parent window couldn't be available. Eg, when
eeschema is executed as standalone on macOS and trying to show
the global design block table dialog before the main frame exists.
So replace the assert with return and check the windows pointers bellow.
Change number of segments of circles to be multiples of 8 and start rotated by delta/2. This ensures that segments will be aligned to a 45°/90° grid
Fixes https://gitlab.com/kicad/code/kicad/-/issues/18654
Edge cases can happen where point + clearance is larger than the bbox.
This can cause the zOrder min and max to get switched as max get a high
bit and is negative. Clamping to limit the input values and using
uint32 for the output solves the corner case
When zone kisses happen from different polygons, we need to be careful
not to use the different polygons for ear comparisons or prev/next
pointers
Fixes https://gitlab.com/kicad/code/kicad/-/issues/18654
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
This tells you the arguments when it fails.
BOOST_TEST is available in all our Boost.Test version.
Even if you didn't use it, these calls should have been
BOOST_TEST_EQUAL(A, B) which also tells you the
arguments on a test failure.
This makes it easier to see which pins have alt modes
available. There is an option to turn them off.
The icon positions are chosen so they they shouldn't
interfere as far as possible:
* If the text is inside, the icon goes more inside
the body
* If the text is above/below the pin, it goes away from
the body
This means it won't collide with a symbol wall in
most cases, but some symbols with alt pins on opposing
sides may need to be widened if the icons are show.
Includes a rather fiddly refactor of the SCH_PIN painter
function, which needs quite a lot of massaging to allow
it to figure out where an icon would go. Quite a bit
of logic is broken out into smaller encapsulations with
less visible state to each chunk.
Icon modes for base-name-selected and alt-selected are
included, but only the former works due to information
being thrown away during the SCH_PAINTER tempPin
process.
Fixes: https://gitlab.com/kicad/code/kicad/-/issues/11069
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 has always been possible (especially through the properties
panel with large scales), but it's even easier if the transform
origin is near a manipulated corner.
Check and reject scales that result in an overflowed image box.
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.
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.
Makes it easier to reason about oval shapes in geometric terms.
For now, this isn't a SHAPE, but it could be (and it's a
fairly common primitive, so it could be useful, though the
obvious use (clearance) is equivalent to a SEG with a clearance,
which is already a function that exists.
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.
In the core geometric types, this can provide some
useful optimisation opportunites.
As most trig functions and std::sqrt aren't constexpr
until C++26, anything that involves a vector length
can't be constexpr yet. But std::clamp and, importantly,
KiROUND are, which does allow quite a bit. And squared
sizes do work, as they are just multiplies, so size
comparisons work too.
The floating point equals-with-epsilon function can't
be directly made constexpr until C++23 (unless std::abs
is replaced with manual code, but that may then forgo
the use of intrinsics at runtime). And they're probably
not important to have at compile-time.
Add a few tests with static_asserts to show/prove that
some non-trivial operations can be done at compile time,
for example BOX2 merging.
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 );
If this is just 'int', BOX2D will not Inflate
as you might expect if given an non-integer parameter,
but will instead do a conversion.
Use coord_type, like the two-parameter Inflate method.
Add a test for this.
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.
Probably doesn't add much directly, but it documents and
enforces the implied contract that the hash is fixed,
and could be used for, say, compile time hash tables.
