Return the EDA_DRAW_FRAME class back to common, whence it came (before it was
duplicated into legacy_wx and legacy_gal). Now there is only one
implementation (the GAL one), it doesn't need to be in a separate library.
This simplifies the dependencies for common lib users.
Since Eagle does not connect stacked NC pins but KiCad will if the pins
are coincident, we choose to only import the first of the stacked NC
pins. While this creates symbols that are slightly different in pin
count from the Eagle version, it keeps the schematic and netlist
functionally correct relative to the Eagle version.
Fixes: lp:1821319
* https://bugs.launchpad.net/kicad/+bug/1821319
(cherry picked from commit 370109b868)
Net names in eeschema that include '/' are escaped ('/' replaced by "{slash}")
Escaped netnames are only for internal use, and must be unescaped in spice netlist and dialogs.
It was escaped (replaced by "{slash}") in dialog.
This is right for labels, not for texts.
A consequence was the directives in spice simul can be broken.
Now the graphic text is not escaped.
Building custom targets that depend on custom commands such as our
keyword lexer requires two layers of indirection to pick up changes
properly and not overwrite the same file in parallel builds.
Fixes: lp:1831643
* https://bugs.launchpad.net/kicad/+bug/1831643
When loading a new file, we do not want to add junctions where they did
not exist before. This could generate invalid netlists by breaking a
wire at a pin connection point.
We do break/add connections when the user modifies the schematic but
this happens while the user is actively working with the component and
sees the action.
Fixes: lp:1830411
* https://bugs.launchpad.net/kicad/+bug/1830411
Also fixes the post-duplicate move to start at the cursor pos.
Also fixes the fact that duplicate wasn't getting its hotkey.
Fixes: lp:1830596
* https://bugs.launchpad.net/kicad/+bug/1830596
This fixes multiple issues when importing Eagle V6 files.
Crashes occured when arcs of 0-length were found and when parts were
referenced in the schematic that were not found in the library. This
could happen if the library and schematic were different cases.
Fixes: lp:1830564
* https://bugs.launchpad.net/kicad/+bug/1830564
This only applies to the root symbol when the datasheet field is not
empty and the datasheet for root symbol alias in the document file is
empty. Use the root symbol datasheet field value when adding a new
symbol that meets this criteria.
The root symbol datasheet field gets copied to the root symbol alias
datasheet member variable so if the symbol is modified and saved, the
datasheet information is saved in the .dcm file.
https://bugs.launchpad.net/kicad/+bug/1830078
Fixes lp:1830078
This only applies to the root symbol when the datasheet field is not
empty and the datasheet for root symbol alias in the document file is
empty. Use the root symbol datasheet field value when adding a new
symbol that meets this criteria.
https://bugs.launchpad.net/kicad/+bug/1830083
Fixes lp:1830083
This is done to allow access to the eeschema library
internals for purposes of test and script access, as the
DLL library has highly restrictive -fvisibility settings
that otherwise prevent the tests being able to access 99.9%
of the eeschema library functions (only a single function
is APIEXPORT'ed, therefore that's the only test we can do).
Using object libraries is a bit of a hack, and makes for
a slower link when done for multiple targets, but with the currently
supported CMake versions, it's about as good as we can get.
A better solution in the longer term may be to break eeschema_kiface(_objects)
into many smaller libraries, each of which has a much more defined scope,
rather than one big interlinked amorphous lump. This has the advantage that
each module is testable in isolation, and we get better organisation of
inter-dependencies in the codebase.
Then, the kiface DLL will gather these sub-libs and present what
is needed on the visible DLL API. Thus, we get both a testable
suite of library functions, and a restricted kiface DLL interface.
If you construct wxTimer statically, it will be constructed
before WX init, which means you might get assertions about
missing m_impl's within the timer class.
The solution is to construct the wxTimer at run time. In this
case, static within the function will be constructed only after
the function is called (and actually the scope only needed to be
this function anyway).
Jeff Young
John Beard
jean-pierre charras
Seth Hillbrand
Jon Evans
Wayne Stambaugh
Michael Kavanagh