The hash table for integer hashes is extremely limited and places most
elements in the same buckets. This leads to a linear search time for
structures built on this.
This blocks hashes, directing the coder to utilize std::set or std::map
structures instead of hash tables for implementing integer-based
lookups.
Auto refill creates a crash when these footprints are moved, probably due to a partial
connectivity rebuild due to refilling when the connectivity data is not yet finalized.
Fixes#11830https://gitlab.com/kicad/code/kicad/issues/11830
Default the new zone priority value to the lowest available unused
priority. Ensures that, by default, a new zone has a unique priority
level preventing zones from unintenionally shorting
Previously new zones' priorities were all set to 0. This is almost
always wrong and can lead to unintended conflicts. The new zone default
value is now set to one higher than the largest number on the board.
This is a better default value because it will not conflict with
existing values.
Tested on msys2 which is the only place it would have been buggy
CMake seems to share the gdiplus linkage with the other dependencies automatically now
When wxAny holds an enum, it cannot be compared with an integer due to a
missing conversion function. In such case, conditional properties
compare a raw value rather than wxAny.
Introduces classes:
- INSPECTED: base class for types taking advantage of
generic properties system.
- PROPERTY*: meta-data storing information about properties
- PROPERTY_MANAGER: singleton class to get properties data
Apparently mapping Eagle footprint layers to the KiCad Dwg_User
that were previously mapped to UNDEFINED_LAYER breaks the QA test
and causes the footprint editor to crash when opening Eagle
footprints. This means that the potential data loss issue when
loading Eagle footprints is still in play.
The Eagle plugin layers have to be mapped differently depending on
whether a board is being imported or a footprint library is being
cached. Footprint libraries can bypass the manual layer remapping
step that happens when importing a board.
Please note that when loading footprints in the footprint editor
and viewer, all layers that do not directly map to KiCad layers are
put on the Dwg_User layer so that there is data loss. Users will
have to manually remap objects to the correct layer as required.
This is less than ideal but until the footprint library table parser
supports prompting users to remap unknown layers, it will have to do.
Fixes: https://gitlab.com/kicad/code/kicad/-/issues/11839
Marek Roszko
Jeff Young
Seth Hillbrand
jean-pierre charras
Jon Evans
Roberto Fernandez Bautista
Maciej Suminski
Alex
Wayne Stambaugh