Using the new ITEM_MODIFICATION_ROUTINE system, drop in two new
tools: chamfer and line extend. These are two geometric operations
that are relatively common when editing footprints in particular.
Chamfer delegates the geometric calculations to a dedicated unit
in kimath/geometry.
Describe the actions of the fillet tools is a generic way, so that the
same general pattern can be used for other tools that modify shapes on
the BOARD.
Basically, an "ITEM_MODIFICATION_ROUTINE" is defined, which is
configured and called multiple times, calling back to the EDIT_TOOL when
it modifies or creates an item.
The motivation here is to make it easier to slot in new line-based
tools like chamfer, extend and so on without having to redo the
complicated item, selection and commit handling each time, and keep the
core "routines" simple and decoupled from the EDIT_TOOL's
internals.
This also resolves#15094 because the new commit handling does the right
thing when items were "conjured up" for the fillet (e.g. when a
rectangle is decomposed into lines).
Fixes: #15094
Note that "immediate" doesn't mean quite the same thing: while it will
enter the tool immediately, it won't necessarily finish the tool during
the call if the tool has an event loop. So for something like Rotate
"immediate" and "synchronous" have the same behaviour, but for something
like Move they do not.
Fixes https://gitlab.com/kicad/code/kicad/-/issues/15085
It had several encapsulation leakage issues, as well as poorly-defined
behaviour of undo for chained-actions (append-to-board, and then rotate
while moving, for instance).
Using a boolean argument just leads to a lot of trailing booleans in the
function calls and is not user friendly. Instead, introduce PostAction()
to send an action that runs after the coroutine (equivalent to passing
false or the default argument), and leave RunAction as the immediate
execution function.
The edit is intended to be on the newly placed dimension, but the actual
properties tool doesn't take an item, so it was always looking up the
item to edit using the current selection/cursor position. Make this more
robust by just calling the edit properties directly on the item.
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.
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).
Change teardrop generation to rely more heavily on BOARD_CONNECTIVITY
for improved performance.
Add updating of teardrops on BOARD_COMMIT::Push().
Also converts m_CopperItemRTreeCache to std::shared_ptr.
We don't copy it around anyway, and having to create a new set
of std::unique_ptr's for each operation is likely to be more
expensive than std::shared_ptr's overhead.
DRC exclusions were originally written following the C++
pragma model (ie: allow this violation here). However, the
"exclusion" terminology we used in the GUI suggests a model
model where the exclusions go away when the violation no
longer exists.
Fixes https://gitlab.com/kicad/code/kicad/issues/14351
Previously, it was not always the edited footprint, but a footprint
selected from the library tree.
It was especially annoying when the footprint was loaded from the board editor:
The footprint was not the loaded footprint, but its copy from library.
Also makes the strings match the GUI better so people will know where
to find them later.
And fixes a couple of ERC items that referred to Board Setup (oops).
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.
(They should only be used when we collect more info before performing
the command. If the command is something like showing the simulator,
then there should be no elipsis as we don't collect more info before
showing the window.)
Also improves a few of the menu tooltips.
We report bitmaps as being 'on' a copper layer because they are
associated with it but they are not actually physical parts so should
not be included in the DRC checks
Additionally, Bitmaps effective shape starts are the top left corner
rather than the center (unclear why that was there in the first place)
Fixes https://gitlab.com/kicad/code/kicad/issues/14065
John Beard
Jeff Young
Ian McInerney
jean-pierre charras
StuartTylerRelytDesigns
Mike Williams
Ian McInerney
Jon Evans
Marek Roszko
Wayne Stambaugh
Lucas Dumont
Nimish Telang
Alex
Seth Hillbrand
Chris Morgan