Not all rectangles want/need the radius point, but we will only be able
to drag one point at a time. So we re-organize which point of an
overlapping set is selected
Fixes https://gitlab.com/kicad/code/kicad/-/issues/21605
Adds scaling handles and editpoints to drag shapes larger/smaller while
maintaining proportions. Future additions might include non
proportional scaling
Fixes https://gitlab.com/kicad/code/kicad/-/issues/13072
Only apply the update point to the EDIT_POINT if it will actually
change. Otherwise the intermediate position before grid snapping, etc.,
caused flickering when dragging with a large grid.
Fixes: https://gitlab.com/kicad/code/kicad/-/issues/19947
This also removes the GROUP/UNGROUP-specific undo actions.
This also fixes a bunch of undo bugs when duplicating
group members, creating pins, etc.
This also fixes some undo bugs when dividing wires etc.
This also fixes some bugs with new sch items not
being created within an entered group.
This isn't the best possible UX (having the various modes immediately
available as graphical affordances would be best). But it's somewhat
discoverable, and at least shows the hotkey, if any, and it in the
context menu and not hidden in a toolbar right click menu. So if the
affordance-type system doesn't make it for v10, this will at least
provide something in eeschema.
This is (now) fairly easy to slot into the PCB point editor
framework.
In this mode, the endpoints adjust only the endpoints on the existing
radius. Radius can ve changed with the midpoint point. The center
point moves the arc, as in the "keep center/adjust radius and angle"
mode.
Fixes: https://gitlab.com/kicad/code/kicad/-/issues/15661
Recommendation is to avoid using the year nomenclature as this
information is already encoded in the git repo. Avoids needing to
repeatly update.
Also updates AUTHORS.txt from current repo with contributor names
Polygon segment dragging no longer pays attention to the
H/V/45 global setting, and now always enforces a drag normal
to the original segment. Polygon vertex editing no longer
enforces a H/V/45 constraint, instead relying on the grid and
object snap.
The chamfer corner action is only meaningful for polygons
and zones, so only enable it there.
Also move some static logic out of of the interface
of PCB_POINT_EDITOR and use SELECTION_CONDITIONS
like other similar code.
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.
