Pads not on copper layers now do not have a netname, and are no longer taken in account in connectivity.
Especially it avoid creating useless rats-nests for these pads.
When generating a complex pad, this allows the user to combine with a
rotated pad and explode rotated pads without needing to rotate elements
to 0 orientation first.
Fixes: lp:1808137
* https://bugs.launchpad.net/kicad/+bug/1808137
This removes the remaining hard-coded segments counts and replaces them
with the relative error calculation where the segments per arc is
determined by the maximum error we allow (smaller arcs = fewer segments)
Allows 0 to 4 chamfered corners, not only one.
A custom shape allow this kind of shape. However because it is a primitive,
it is easier to edit and it support thermal reliefs.
When adding an element to a module, we don't need to update the relative
coordinates. Doing so can cause changes when writing to file depending
on rotation and position.
Fixes: lp:1810870
* https://bugs.launchpad.net/kicad/+bug/1810870
When designing pads, it can be helpful to not only see the resulting
rounded rectangle radius from a given percentage but also to set it,
constraining the related percentage. This adjusts the dialog to allow
editing the rounded rectangle corner radius. It does not change the
file format as the resulting ratio is saved. Further updates of the pad
size or ratio will modify the radius.
Fixes: lp:1668020
* https://bugs.launchpad.net/kicad/+bug/1668020
Well, almost anyway. We can't use a pad attribute for them as
that would change the file format. So they're currently
defined as a CONN pad with no copper layers.
However, when figuring out of existing pads should be *treated*
as aperture pads, we just check for no copper layers.
Fixes: lp:1781760
* https://bugs.launchpad.net/kicad/+bug/1781760
... and GetMsgPanelInfo.
Step 4 in the g_UserUnit eradication effort.
Also removes a couple of conversion routines that were close
enough to extinction.
(cherry picked from commit c75da51)
- pad names are stored as wxString instead of a char[4] & integer union
- removed pad name to string conversion functions
- fixed pad & pin properties dialog restrictions regarding the name
length
eeschema now supports arbitrary colors for all object types, and
pcbnew does in GAL canvas. When switching from GAL to legacy canvas,
pcbnew will convert colors to the nearest legacy color.
bitmaps.h was included in nearly every file in the project due to it
being included by base_struct.h
Only about 130 files actually use the XPM definitions defined there, and
many of those already included bitmaps.h themselves, or via
menu_helpers.h. However, touching bitmaps.h would result in over 400
rebuilt files for pcbnew alone.
This commit moves the bitmap-related types like BITMAT_DEF out to a new
header, which is still included by base_struct.h, which is less
avoidable for now, it's it's used in the interface.
The icon list is still in bitmaps.h. This has the side effect that's
it's now easier to automatically generate this file.
Many classes in pcbnew and eeschema needed some functions moved
to the implementaitons from the headers too.
Some accessors should be const:
* IsFlipped
* GetRoundRectRadiusRatio
Returning a objects by value as const in these cases is not helpful, as
all it does is prevent the caller moving from the return value, it just
forces a copy.
Some of thse functions come from base class overrides, those haven't
been changed.
* ShapePos
* GetPadName
* GetPackedPadName
Jeff Young
jean-pierre charras
Seth Hillbrand
Tomasz Włostowski
Marvin Schmidt
Maciej Suminski
Wayne Stambaugh
Oliver Walters
Jon Evans
John Beard
Simon Richter