For segment, circle, beziers, these are the same in all editors and only
need access to the EDA_SHAPE nature, so we can remove the duplication
entirely.
For TABLECELLs, while the cells are polymorphic in that PCB and SCH
cells are both EDA_SHAPEs (via the TEXTBOXes), the parent TABLES
are not polymorphic, and thus the implementation can't be trivially
de-duplicated. Rather than do something with templates, just keep
it simple for now and maybe look at unifying tables later on.
This adds the concept of editing _other_ items to the one
that informs the POINT_EDIT_BEHAVIOR - in this case connected
lines. This is one of the motivations behind this system,
as it will allow to bring similar logic to Pcbnew.
Saving the best for last - the one that wound me up enough to
start this process - textboxes, which sometimes, but not always
behave like rectangles.
Rather than some exciting multiple inheritance of
RECTANGLE_POINT_EDIT_BEHAVIOR and a hypothetical rotated
rectangle behavior, delegate the rectangular behavior to
static helpers in the rectangle one.
They still can't be edited when rotated, but at least now there
is some hope that it's tractable!
Especially the aligned dims are fiddly, but all the
dimensions need the array size to be carefully kept
controlled, which is now part of the invariant of
each behavior.
This also changes the interface on the GENERATOR classes
to no longer take a shared_ptr - these methods are synchronous
and don't store (shared) ownership of the EDIT_POINTs.
This is a pretty straightforward one
(though there was a latent bug here because both CIRCLE
and ARC used CIRC_CENTER for the constrainer. If an ARC
and CIRCLE center were not the same index (and nothing says they
have to be) that could be wrong or crash.
This is a good example of an edit behaviour that had a lot
of code in PCB_POINT_EDITOR that was only used for a single
item type. Many of these (now static) functions will probably
find use in other places arcs crop up like filleted shapes
and also in eeschema.
But for now, keep it simpler and keep them near where they
are used.
This introduces the POINT_EDITOR_BEHAVIOR class, which
allows a "behavior" to be defined, which covers the creation
of edit points, updating the points on edit, and pushing the
edited points back into the object.
This keeps the logic for a single item "type" (e.g. a SEGMENT
or TEXTBOX, etc) in one place, rather than fragmneted throughout
the POINT_EDITOR class, where the invariants like point count
are difficult to keep track of as the TOOL progresses.
For now, it's implemented as an optional class, just for SEGMENT
and other tpyes work as before. Adding new types is then a
"pin-compatible" drop-in process.
When in rectangle mode, it still needs to act like a rectangle, but
it doesn't go through the usual PCB_SHAPE handler (even though it is
a PCB_SHAPE too).
Useful both as a confusion reduction measure when confronted with the
inforbar message, and also useful when you pressed Ctrl+E, not
Ctrl+Shift+E.
Also bind Ctrl+Shift+E in the editor to perform this action
(again, useful when you used the wrong hotkey).
This involves recasting the array tool from the slightly
eccentric ARRAY_CREATOR class into a full-blown TOOL, which
allows it to usefuly store state asd the dialog hides. This
is modelled on the POSITION_RELATIVE_TOOL strategy.
The by-radius-and-point mechanism is removed entirely,
as it's very fiddly and hard to describe in the UI,
and what you probably really want to do is get your
item onto the circle with tools like "move exact",
and then define the circle origin (now using the picker
tool)
Fixes: https://gitlab.com/kicad/code/kicad/-/issues/16783
This moves the interactive pick point/item tool action to
PCB_PICKER_TOOL, and add a parameter to allow it to be useful for other
tools that want to pick a point from the canvas.
Pass things as unqiue_ptrs. I don't think there's that much
on the stack, but certainly addinig big enough chunks to the batches can
upset the coroutines.
Also reinstate a ClearDrawables which went AWOL.pick
Relates-To: https://gitlab.com/kicad/code/kicad/-/issues/18835
Primary increment is the right most bit, secondary is the next
rightmost. So you can increment 'A1' to 'A2' or 'B1' with
Shift-Alt-Scroll and Ctrl-Alt-Scroll respectively.
Implemented as handling un-consumed scroll events that the
WX_VIEW_CONTROLS doesn't want because it has too many mods
set. Then dispatch these as TA_MOUSE_WHEEL events.
The default action from the selection tools is to run the
'increment' ACTION, which is implemented differently in the
various tools: eeschema can increment labels, symedit
does pin names and numbers, and fpedit does pad numbers.
These are context sensitive actions that increment "something"
about the selected item.
A generic 'increment' action can be produced, e.g. by other tools
or UI events, which has in increment step (positive or negative)
and an 'index' which determines what about the item should be
incremented - it's up to the increment action handler to decide
what that means.
And then add a primary and secondary inc/decrement action,
which allows to bind hotkeys to each.
Bind these to:
* Sym edit: increment pin names/number
increment text items
* Sch edit: increment lables and text
* FP/PCB: increment pin numbers
increment text items
When using "New Footprint" from a selected library in the tree view
(or with an open footprint in such a library) that is read-only,
the new footprint will now be created in a "non-library-assigned" state
so the user has to Save As to save it to a library.
There will also be a warning when this happens to (try to) be less
mysterious about what just happened.
This patch uses a similar logic to that provided by Jan Wichmann in
MR !2034 - thank you!
Relates-To: https://gitlab.com/kicad/code/kicad/-/issues/18923
This MR adds a new DRC Test provider for the angle between two connected Track segments.
Rule example:
(rule test_track_angle (constraint track_angle (min 135)) (severity error) )
John Beard
JamesJCode
Jon Evans
Alex Shvartzkop
Tomasz Wlostowski
Andrej Valek
Fabien Corona
Jeff Young
Daniel Treffenstädt
Denis Latyshev
jean-pierre charras