This allows common operations like merging a pin courtyard
into the body courtyard in the fooprint editor, taking a
"bite" out of a polygon and so on,
For now, this only supports polygons made of straight lines.
There are some wierd cases when the operations result in nothing
(e.g. wen a big polygon is substracted from a smaller one that
it contains entirely). I have tried to do something senisble in
these cases, but there may be more optimal ways to handle it.
Relates-To: https://gitlab.com/kicad/code/kicad/-/issues/13025
Create 2 wrappers for it: DIALOG_FOOTPRINT_CHOOSER and
FOOTPRINT_CHOOSER_FRAME. The first now gets called from wxGrid
editors, text button editors (such as Change Footprints), etc.
Retire FOOTPRINT_VIEWER_FRAME_MODAL. FOOTPRINT_VIEWER_FRAME still
exists, but has very few uses at this point.
Previously the snap points computed for oval pads didn't get all the
points correct. This breaks out the "find snap points for ovals"
into a function, reworks the logic, adds some tests.
Also adds "extremum points" when the oval isn't exactly H/V.
Fixes: https://gitlab.com/kicad/code/kicad/-/issues/15594
- Move PLUGIN_FILE_DESC to common.
- SCH_PLUGIN: rename Load -> LoadSchematicFile, Save -> SaveSchematicFile.
- Use PLUGIN_FILE_DESC and CanRead* in schematic plugins.
- Return none/unknown types from Find/GuessPluginType functions.
- Iterate over file types for file wildcards.
- Clean-up header checking in IO plugins.
- Use PCB plugin list in IO_MGR::GuessPluginTypeFromLibPath.
Graphic shapes (excluding text) can now have nets when on
copper layers. Shapes behave like tracks in that they will
pick up nets from connected pads, and follow track opacity
settings.
If we have a footprint currently selected and we click on its empty
space again, we deselect the footprint. However, if we click on the
empty space of a different footprint, we will select that footprint
instead.
Fixes https://gitlab.com/kicad/code/kicad/-/issues/15284
- Footprints cannot be selected if they do not have items visible on the
screen
- Clicking on empty space in a footprint will select it if the space is
contained in the visible bounding box
- Clicking on a selected footprint a second time will deselect it
- Clicking on a footprint that has pads selected will still select the
footprint
This avoids having the full footprint bounding box considered when
selecting footprints (useful b/c footprint bbox is often much larger and
unexpected). Also allows non-standard footprints (e.g. silk or fab only
footprints) to be logically selected if the layers on which they have
elements are visible.
Fixes https://gitlab.com/kicad/code/kicad/-/issues/15284
When working in high contrast mode, we want to be able to select a
footprint with only elements in, e.g. silk and fab layers.
The previous design for footprint IsOnLayer had one behavior of every
other element and a different behavior for footprints. This leads to
multiple bugs as new features use the overloaded IsOnLayer expecting it
to report if the element exists on a layer or not.
For footprints, we need a different routine to determine whether or not
to select the footprint when clicking on it. IsOnLayer will report if
the footprint has any elements on a specific layer but we don't want to
use the bbox for a hittest because large footprints with through hole
pads will exist on every layer and have an enormous bbox. Instead, we
filter footprints based on the hittest of each element. This behaves in
a more logical fashion, allowing you to select a footprint by clicking
on a visible element of that footprint.
Fixes https://gitlab.com/kicad/code/kicad/-/issues/15284
This needs the ITEM_MODIFICATION_ROUTINE to learn to delete items.
Condense the item change handlers into a single injected object
(ITEM_MODIFICATION_ROUTINE::CHANGE_HANDLER) and provide the basic
implementation that just takes some callables.
This simplifies the construction of the routines and also would make
a CHANGE_HANDLER object possible that can be reused between different
tools.
In the EDIT_TOOL::ModifyLines method, there was some
remaining special-casing for FP childen commits.
One bit was put back by mistake (in
0b32ae3f4b) because I thought I'd
left it out of the refactor. In fact it was removed slightly later in
1218f61d0a.
THe other bit is omitting Modify commits in the FP-editor (what the
reinstatement of the above code was trying to cause). This shouldn't
be needed any more.
However, something is still incomplete here as the tools still don't
work correctly in the footprint editor. However, I don't think it's
substantially _more_ broken with the special casing removed and at
least it's less confusing.
Related to: https://gitlab.com/kicad/code/kicad/-/issues/15253
Also includes persisting settings for next dialog invocation
and use the TransferDataFromWindow function rather than per-field
accessor methods.
Fixes: https://gitlab.com/kicad/code/kicad/-/issues/10651
The draft fill and single zone unfill would only work if something was
selected first, this allows them to call the selection operation to
request what is under the cursor. Also properly gate the operation to
not cause crashes/issues when the selection contains non-zone items.
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
Jeff Young
John Beard
Marek Roszko
Zhuang Jiezhi
Seth Hillbrand
Alex Shvartzkop
Jon Evans
jean-pierre charras
Josue Huaroto
Mike Williams
Ian McInerney
Roberto Fernandez Bautista
Ian McInerney
StuartTylerRelytDesigns