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.
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.
Issue raised by TomW, points included in new QA test where Simplify was
not properly removing colinear points.
Also removed TestSegmentHitFast() as the speed gains were minimal when
testing against the revised SEG::SquaredDistance routine in
TestSegmentHit()
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.
We are calculating the same value in two different ways. If there is an
off-by-one issue in our calculation along axis, this still means that it
was a direct hit on the line as seen in the unit test cases
This means that it doesn't start consuming hotkeys for
IME composition in the main canvas on Linux.
Text boxes in dialogs and the property manager, for example,
still receive IME composition.
Relates-To: https://gitlab.com/kicad/code/kicad/-/issues/9882
Previous function would drop some KiROUND calls due to inability to
parse the () operator. Using the _v template gets the constexpr check,
allowing us to avoid the conditional while running
We don't actually need the closest point to figure out the distance.
Since this calculation is used everywhere, we see some non-negligible
gains by picking the length along the projection
line chains that are not closed should avoid simplifying between
beginning and end points. Make sure that we keep the finishing point
for these chains
Fixes https://gitlab.com/kicad/code/kicad/-/issues/18409
(cherry picked from commit b71eb1186f)
When calculating a part of the polygon area and thus ending the polygon
at the specified vertex aEnd we need to calculate and add the area below
the needed additional line from "aEnd" to "this" to close the resulting
partial polygon. As in this case VERTEX* p references "aEnd" after exiting
the do-while loop the correction term in the if-statement was always
evaluated to zero. Change "aEnd" to "this" in the correction term.
Seth Hillbrand
John Beard
Alex Shvartzkop
Lucas Dumont
Alexander Rauth