Before, if the tools were activated from the context menu,
they would start drawing where the menu item was selected
instead of where the menu was opened.
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
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)
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
When dragging, you will seldom want to snap to the original item. This
commit prevents the "size of track" snap to the original item and
replaces it with an auxilary grid origin for the snap. This means
effectively that the snap will happen to grid for the original item
unless the cursor is closer to the original item line than it is to the
grid crossing.
Fixes: lp:1820248
* https://bugs.launchpad.net/kicad/+bug/1820248
The selection for interactive drag uses cursor position off grid to
choose the element for dragging. We pass the same value into the start
dragging routine to choose the correct end of the element.
Fixes: lp:1813665
* https://bugs.launchpad.net/kicad/+bug/1813665
When changing the track width, we need to allow that the track's route
will change based on DRC, so force a move without changing position.
Fixes: lp:1785057
* https://bugs.launchpad.net/kicad/+bug/1785057
Using Title + Message wasn't working for all the dialogs which
did substitutions in the message (which was a lot of them).
Fixes: lp:1789348
* https://bugs.launchpad.net/kicad/+bug/1789348
After an action is completed that required the screen to pan when the
cursor reaches the edge of the screen, we should release the cursor to
allow the user to move their mouse without panning.
Fixes: lp:1763860
* https://bugs.launchpad.net/kicad/+bug/1763860
- Ordering of Hotkey list by function
- Use Hotkey assignment instead of hard-coded hotkey for length tuning
- Adjust default Length Tuning settings hotkey to CTRL-L so that we
don't overlap with "Lock" (overlaps are not editable)
Corrects an error in polyline estimation
Syncs graphics to world PNS by whole layer set rather than
individual layer at a time.
Prevents reloading of full pns TOOL_BASE during reset of tools unless
the tool is being activated.
Fixes: lp:1766626
* https://bugs.launchpad.net/kicad/+bug/1766626
Track dragging forces the cursor position, which is still kept when PNS
router is launched again. It is avoided by resetting the force cursor
position option before running the event loop.
Launching right click context menu overrides the cursor position, so all
actions executed by the tools will be performed in the right click
position. It created an issue, as the overridden cursor settings were
saved into wrong context if there was another tool activated in the
meantime.
Current implementation saves cursor settings for all tools and restores
them once the right click context menu disappears.
Fixes: lp:1745981
* https://bugs.launchpad.net/kicad/+bug/1745981
Fixes: lp:1746507
* https://bugs.launchpad.net/kicad/+bug/1746507
Ian McInerney
Jeff Young
Seth Hillbrand
Tomasz Włostowski
jean-pierre charras
Franck78
Maciej Suminski
Jon Evans