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
* Switched hashtables.h over to std::undordered_map from boost version.
* Added new macros DECL_VEC_FOR_SWIG() and DECL_MAP_FOR_SWIG() in macros.h.
These along with future DECL_HASH_FOR_SWIG() unify the declaration to swig
and C++ so that the resultant type name is common in both languages, and
the types AGREE.
* Fixed swigging of NETINFO_ITEM and NETINFO_LIST via magic.
* Newly exposed (python wrapped) are: D_PADS, TRACKS (was TRACK_PTRS),
NETNAME_MAP, NETCODE_MAP, wxString (without constructor purposely, read
comment in wx.i), MARKERS, ZONE_CONTAINERS, NETCLASSPTR, KICAD_T types.
* std::vector<SOMETHING*> tends to end up named SOMETHINGS in C++ and python.
Having the name consistent between like types is helpful, and between
languages. std::map<> ends up as SOMETHING_MAP.
* NETINFO_LIST::m_netNames and NETINFO_LIST::m_netCodes are now std::map
instead of hashtables, because swig does not yet support std::unordered_map.
* You can now get to any netclass or net info. NETNAMES_MAP and NETCODES_MAP
are traversable basically the same as a python dictionary using a python
string (not wsString) as the key! The wxString typemap converts python
string to wxString before the lookup happens. Iteration also works.
It should help if (or when) the internal angle unit used in kicad will be changed from 0.1 degree (a relic of code written for PCs without fpu) to degree ( a more natural unit).
PAD_SHAPE_T and PAD_ATTR_T still have a double definition (new names and old names) to be sure python scripts are nor broken by the change.
PAD_DRILL_SHAPE_T does not have a double definition, because it is unlikely oblong holes are used in python scripts.
Double definitions will be removed in the (next) future.
Jeff Young
jean-pierre charras
Tomasz Włostowski
Marvin Schmidt
Maciej Suminski
Wayne Stambaugh
Oliver Walters
Jon Evans
John Beard
Simon Richter
Dick Hollenbeck
https://launchpad.net/~john-j-beard