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
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.
Marek Roszko
jean-pierre charras
Jon Evans
Mike Williams
Jeff Young
Seth Hillbrand
John Beard
Ian McInerney
Ian McInerney
StuartTylerRelytDesigns