Using std::any from C++17 allows for proper type handling in the
parameter field, removing the need for casting to void* and then casting
the void* to the desired type.
1) Also reorders parameters to make sure the compiler helps out.
2) This also makes it harder to mess up the discrepency between
BOX2I/wxRECT/etc::Inflate() and SHAPE_POLY_SET::Inflate.
3) Also fixes a couple of bugs where the corner strategy was passed
in as a segCount.
4) Also fixes a couple of bugs where the error wasn't forced to the
outside to match the ERROR_LOCATION.
5) Also fixes a couple of bugs where the seg count was specified
without regard to an already passed-in max deviation
Don't open-code knockout text shape generation in several different
places.
Make sure triangulated knockout text gets clearance added when
specified.
Collapse duplicated footprint text item plot routine (they're no
longer any different from plotting pcb text items).
A sheetpath is required to correctly resolve text variables.
Depending on currentSheet is rife with bugs.
There are many places where we do *not* want to be prepending
field names to the field values, such as netlisting,
building PDF hypertext menus, etc.
Also, Find/Replace needs to work on unresolved text, as
that's what we're going to display (and if replace nuked
your variable references you wouldn't be happy).
The spacemouse driver, particularly on Mac, is extremely unstable and
causes crashes even when not being used. This places the interface
behind an advanced config flag to ensure that users can affirmatively
opt-in to the potential for crashes
This library is meant to move non-EDA items (language extensions,
library extensions, etc.) into the lowest-level of our dependency chain.
This library should never depend on anyother non-thirdparty code in the
kicad codebase.
Don't assume the dialog is mode-less and call Destroy() from within a
dialog method. This will most assuredly crash if the dialog is shown
modally or quasi-modally.
Don't leak memory for mode-less dialogs created on the stack. Make sure
when the parent frame window is closed that all mode-less dialog memory
is cleaned up. Dialogs are not child windows like controls and toolbars
so their memory does not automatically get cleaned up when the parent
window is destroyed.
Do not directly access frame parent window's pointer in dialog destructors.
Apparently the tear down order when destroying mode-less dialogs is not
guaranteed so the parent window may get deleted before the dialog causing
a crash when accessing the parent window pointer from the dialog dtor.
Do not close mode-less dialogs in the parent frame's destructor. This
doesn't guarantee that the dialog(s) will be destroyed before the parent
but it may reduce some careless mode-less dialog event handling in the
future.
Ian McInerney
Mike Williams
Jon Evans
Alex Shvartzkop
Jeff Young
Marek Roszko
jean-pierre charras
qu1ck
Seth Hillbrand
Wayne Stambaugh
Ian McInerney
Mario Luzeiro
aris-kimi