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).
- Move under rectangular selection
- Simplify available modes
- Link to new icon
- Make selection state persistent
- Allow additive/subtractive with KiCad configurable keys
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
ki::any is a standards-compliant implementation, based on the GCC
standard library. However, it uses type_info::hash_code() to check
the validitiy of a ki:any_cast, rather than comparing the type_info
objects directly. This comparison, used in the standard
implementations, is fragile across translation unit boundaries when
built with Clang.
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
The WX_COMPATIBILITY mode is always assumed now (the option was removed
previously), but the define is no longer present. So remove the old code
that checked for it and just leave the wxASSERT statements.
Using std::any from C++17 allows for proper type handling in the
parameter field, removing the need for casting to void* and then casting
the void* to the desired type.
We're getting segfaults in places where this isn't checked. Also, add
some asserts so we can catch bad tool push/pop.
Removes all uses of GetCommandStr() and makes it private.
This standardizes selection tools in SELECTION_TOOL class to be able to
handle a long-click as asking for a non-heuristic disambiguation menu.
Fixes https://gitlab.com/kicad/code/kicad/issues/8490
The move tool can stack on others, so when we re-enter the previous tool
this caused another immediate action. We flag re-entry in the tool
stack to check for this and avoid unexpected tool starts
Can happen if someone hammers away on the probe and/or tune tools
without ever mousing over the schematic in between.
*May* fix the below bug.
Fixes https://gitlab.com/kicad/code/kicad/issues/6876
* Make the events generated by the selection of context menu items
have the position where the menu was opened
* Ensure that TC_COMMAND type events have their position set to
be the cursor position where the event originated
We were running into various corner conditions where a tool's event
loop would exit while the tool was still active, or the tool would
get popped while we were still in the event loop. (A lot of these
had to do with the POINT_EDITOR's, but not all of them.)
The new architecture:
1) tools always do a Push()/Pop()
2) everyone is responsible for their own pops; no more stack-clearing
on a cancel
3) CancelInteractive events go to all tools to facilitate (2)
If a tool called something like clearSelection while processing a
MOUSE_CLICK, the SELECTION_TOOL will pass the clearSelection
COMMAND_EVENT because it handles it as a transition, not as an
event. Because m_passEvent is effectively global, the tool manager
would then interpret that as passing the MOUSE_CLICK and we'd end
up processing the click by multiple tools.
