Always look for pre-existing undo/redo record. Checking for IsNew()
is less robust and should be avoided. Also moves the checking to a
location where it will be easier to ensure that it's uniform.
Push get-undo-level-item processing down a level so it is uniformly
called.
Make sure tables & labels are uniformly handled.
Remove incorrect usage of Get/SetGroupId() for storing lastPin
(which we don't use anyway).
Lists of deleted and changed items MUST include the screen pointer.
An item could be changed on one screen but not on another.
Also tightens handling of PCB_NETINFO_T items, which are not in the
view.
Also fixes a bug where there is no increment parameter if you assign
the base increment command to a hotkey.
(This was discovered while testing the above changes.)
Also fixes a bug where delete during a move in PCB Editor did an
undo instead of a delete.
(Again, found while testing above.)
An experiment was also run to collapse shared parts of SCH_EDIT_FRAME
and SYMBOL_EDITOR_FRAME into SCH_BASE_EDIT_FRAME. However, sharing the
undo code actually increased complexity, and there was very little else
of value in SCH_BASE_EDIT_FRAME (other than the Increment() routines).
The ST MB2046 reference board, for example, has all the
assembly-layer ref-des text in the format '.R42' even though
they're not concatenated.
Enable the existing but commented-out text.
This adds the ability to export the pin table content to a CSV file
or the clipboard as CSV, then re-import it from CSV or TSV. This allows:
* to round-trip pin table data via a spreadsheet program, so that the pin
data can be manipulated in a richer/more familiar editing environment
* an import method to bring in tabular pin data from other formats
"semi-automatically", without having to write a full-blown symbol generator.
Relates-To: https://gitlab.com/kicad/code/kicad/-/issues/19207
Not sure what it is that caused it to break (reported by
Seth on Linux, but works for me and on the CI).
Rather than trying to be clever at this point, just do the dumb
thing (and remove the boost_test_print_type for wxSize to prevent
someone using it for the time being).
The m_imageData buffer in the BITMAP_BASE is an
internal implementation - the public API to persist the
data to a stream appears to be SaveImageData - so use that,
which hides the implementation (and generates the image data
"live" when needed).
Remove the public access to the m_imageData buffer as it isn't
needed for public use, and also is misleading.
Also break out the formatting of the data into KICAD_FORMAT,
as it's currently replicated in eeschema/pcb/pagelayout
formatting code.
Fixes: https://gitlab.com/kicad/code/kicad/-/issues/19772
Recommendation is to avoid using the year nomenclature as this
information is already encoded in the git repo. Avoids needing to
repeatly update.
Also updates AUTHORS.txt from current repo with contributor names
ki::any is a standards-compliant implementation, based on the GCC
standard library. However, it uses type_info::hash_code() to check
the validitiy of a ki:any_cast, rather than comparing the type_info
objects directly. This comparison, used in the standard
implementations, is fragile across translation unit boundaries when
built with Clang.
UNDEFINED_LAYER is -2, so simple checking evenness isn't
enough to check if it's copper or not. Notciable when the
FABMASTER import puts things on UNDEFINED_LAYER while it's
processing items.
Primary increment is the right most bit, secondary is the next
rightmost. So you can increment 'A1' to 'A2' or 'B1' with
Shift-Alt-Scroll and Ctrl-Alt-Scroll respectively.
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.
Mostly intended right now for allowing testing of library tables
to help with testing chained loading, but it also decouples the
idea of a library table from on-disk files in general.
All current (real) lib table implementations continue to use the
file-based IO.
This could be made more general (not just for tables) if really
needed.
F_Cu = 0
B_Cu = 2
Remaining internal copper layers are even and incrementing
Non-copper layers are odd and incrementing.
This means that we can no longer do things like:
for( PCB_LAYER_ID layer = F_Cu; layer <= B_Cu; ++layer)
Instead, we have the class LAYER_RANGE:
for( PCB_LAYER_ID layer : LAYER_RANGE( F_Cu, B_Cu) )
Similarly, gt/lt tests should not refer to the integer value of the
layer. We have functions such as IsCopperLayer to test whether a layer
is copper or not.
When using the connectivity RTree, the third dimension is layer, so we
provide B_Cu with the special INT_MAX value, ensuring that elements
between F_Cu and B_Cu will be identified. There is a new, special
function GetBoardLayer() for interfacing with CN_ITEMS
Similarly, PNS layers remain unchanged and sequential. A set of
interface functions is provided to map PNS layers to Board layers and
back. This allows the PNS_LAYER_RANGE to function as expected
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.
Since Boost 1.64, you can use the boost_test_print_type
customisation point to provide test printing for types.
Move all test printing functions to this, and scrap the
fiddly Boost version handling to deal with older Boosts
(KiCad is now at minver 1.71).
Schematics, symbols, boards and footprints all get the ability to store
files inside their file structures. File lookups now have a
kicad-embed:// URI to allow various parts of KiCad to refer to files
stored in this manner.
kicad-embed://datasheet.pdf references the file named "datasheet.pdf"
embedded in the document. Embeds are allowed in schematics, boards,
symbols and footprints. Currently supported embeddings are Datasheets,
3D Models and drawingsheets
Fixes https://gitlab.com/kicad/code/kicad/-/issues/6918
Fixes https://gitlab.com/kicad/code/kicad/-/issues/2376
Fixes https://gitlab.com/kicad/code/kicad/-/issues/17827
