Always look for pre-existing undo/redo record. Checking for IsNew()
is less robust and should be avoided. Also moves the checking to a
location where it will be easier to ensure that it's uniform.
Push get-undo-level-item processing down a level so it is uniformly
called.
Make sure tables & labels are uniformly handled.
Remove incorrect usage of Get/SetGroupId() for storing lastPin
(which we don't use anyway).
Lists of deleted and changed items MUST include the screen pointer.
An item could be changed on one screen but not on another.
Also tightens handling of PCB_NETINFO_T items, which are not in the
view.
Also fixes a bug where there is no increment parameter if you assign
the base increment command to a hotkey.
(This was discovered while testing the above changes.)
Also fixes a bug where delete during a move in PCB Editor did an
undo instead of a delete.
(Again, found while testing above.)
An experiment was also run to collapse shared parts of SCH_EDIT_FRAME
and SYMBOL_EDITOR_FRAME into SCH_BASE_EDIT_FRAME. However, sharing the
undo code actually increased complexity, and there was very little else
of value in SCH_BASE_EDIT_FRAME (other than the Increment() routines).
This will also handle the case when more than two items are subtracted,
e.g. many small items witrhin one larger item. Again, thanks to
Kliment for a smart idea!
While there is technically some kinds of defined order (last selected item is
'A' in the 'A - B (- C...)' operation, it's easy to drag select and then
get a null result.
So if this happens to a non-commutative operation, try again in the
reverse order. In the usual case (2 items), this will get what the user,
presumably, wants. If there are more than 2, it will either work, or the
user can undo and try merging the "B" operand before subtracting, or do
them one at a time (at which point the order-reverse logic will help
again).
Thanks to Kliment for an this usability suggestion!
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.
Cloning the item into the previewe means that if we later increment
it, the preview clone doesn't update. Use the non-owning preview
interface to use the item directly in the preview.
Fixes: https://gitlab.com/kicad/code/kicad/-/issues/19433
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
The TOOL_EVENT constructor searches for ACTONS::cancelInteractive. That
action is global, so we need to ensure it is created before we try to
create these events - so switch to a create on first use paradigm for
the events.
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
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
This is useful when you want to copy text content out to some
external program (or put it in a text item/box).
I'm not sure it's possible to intuit exactly what a user wants,
as you will often want to copy items as the real items, and sometimes
as text. While KiCad might be able to make a smart guess, external
programs will have no chance!
