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)
It's a bit of a hack because they're statically initialized and
so we can't make use of the _() macro. We do still want it in the
code, however, because the string harvesting is based off of it.
Fixes: lp:1833000
* https://bugs.launchpad.net/kicad/+bug/1833000
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.
Set the IS_NEW flags so the POINT_EDITOR doesn't try an poke its head
in, and apply the EE_SELECTION_TOOL hack for mouse clicks leaking
through to the underlying tools.
Fixes: lp:1832911
* https://bugs.launchpad.net/kicad/+bug/1832911
The dynamic ratsnest is shown while moving items but this needs to be
hidden after cancelling. Previously this was handled by the
SelectionClear event but we've changed this to (correctly) keep the
previous selection when canceling.
Fixes: lp:1831350
* https://bugs.launchpad.net/kicad/+bug/1831350
When routing in high-contrast mode, the user may wish to place items
that are primarily on a different layer while remaining in high contrast
mode. This fixes a regression from 4.0.7
Fixes: lp:1804309
* https://bugs.launchpad.net/kicad/+bug/1804309
Checks for ratsnest enabled prior to calculating and displaying the
local/dynamic ratsnest. Calls the ratsnest clear from selection clear
Notably, it appears that the tool actions do not chain transitions for
the same event. So only a single action (first specified) will be
executed when an event fires unless the actions are executed by separate
tools.
Fixes: lp:1809752
* https://bugs.launchpad.net/kicad/+bug/1809752
Instead of a nag screen for locked items, we allow first the unlocked
items to be deleted and then, with a repeated request, the locked items.
This adds a popup cursor window informing the user of the option for
repeating the delete
Fixes: lp:1806507
* https://bugs.launchpad.net/kicad/+bug/1806507
The client filter might add items in the case where locked pads are
filtered. We need to handle this case when requesting selection by
adding new items to the m_selection
Fixes: lp:1802686
* https://bugs.launchpad.net/kicad/+bug/1802686