The Get and place tool used to live in selection tool and could activate
the edit tool by stacking calls. Now that it is itself in the edit
tool, we cannot stack another call to the edit tool that runs
immediately, instead we allow the GetAndPlace to finish before beginning
the next tool (Move)
The problem is that wxEVT_CHAR_HOOK doesn’t do the key translation
properly. wxEVT_CHAR does, but we only get to that if we skip the
event at the end of the tool’s event processing loop, which most tools
don’t do. (Selection tools, point editors, pickers, and a couple of
others do skip, which is probably why this didn’t get reported earlier.)
I played around with a couple of ways to fix wxEVT_CHAR_HOOK. Most of
them don’t work, and the few egregious hacks I tried weren't cross-
platform.
So I’m changing it so that most tools now skip at the end of their
event loops. I left out a couple that I felt were high risk (length
tuning, for instance). But there’s still enough risk that I’m 100%
sure it will break something, I just haven’t a clue what.
Fixes: lp:1836903
* https://bugs.launchpad.net/kicad/+bug/1836903
Because the pickers are called with an Activate()/Wait() pair, any
usurping tool gets in between the picker handling the cancel (due
to activation) and the picker client doing a PopTool(). The new
tool is therefore pushed before the old tool is popped.
Fixes: lp:1835907
* https://bugs.launchpad.net/kicad/+bug/1835907
Includes the addition of an onSetCursor() handler which must be called
from both the GAL canvas AND the GAL backend (at least on OSX) to prevent
cursor flickering between (for instance) pencil and arrow.
Also includes new architecture for point editors which allows them to
coordiate cursors with the editing tools (so we can switch to an arrow
when over a point).
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)
This checks the movement against a maximum value that would place the
selection outside of the valid area for the footprint or board.
Fixes: lp:1833478
* https://bugs.launchpad.net/kicad/+bug/1833478
(cherry picked from commit 845833e8fd)
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
Prevents certain edit tools from handling the action unless the cursor
remains inside the selection bounding box.
For now this is a UX test but the behavior may be expanded into Eeschema
as well.
Fixes: lp:1827242
* https://bugs.launchpad.net/kicad/+bug/1827242
Mouse capture end is called by some actions such as save board. This
resets the cursor image but doesn't change the current tool. Resetting
the cursor image during action prevents this.
(cherry picked from commit 35e87128f5)
Fixes: lp:1831888
* https://bugs.launchpad.net/kicad/+bug/1831888
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
Jeff Young
Seth Hillbrand
Ian McInerney