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.
Getting the position of a non-position TOOL_EVENT will
now result in a wxCHECK, and a null-position (0,0) will
be returned. The new interface HasPosition() can be used
to determine if a call to a position function is safe to
make from the caller.
Fixes the underlying danger behind lp:1796045, which has
already been neutralised by a4966adb6, which avoids calling
the Position() functions when the TOOL_EVENT is not known
to be a position.
Fixes: lp:1796045
* https://bugs.launchpad.net/kicad/+bug/1796045
It fixes the case when a tool sets up a menu and starts its event loop
waiting exclusively for menu events. If none arrived, the tool was stuck
in the loop forever.
Fixes: lp:1744915
* https://bugs.launchpad.net/kicad/+bug/1744915
Ian McInerney
Kuba Sunderland-Ober
jean-pierre charras
Jeff Young
Ian McInerney
Mike Williams
Seth Hillbrand
Marek Roszko
Mikolaj Wielgus
Dominik Wernberger
Wayne Stambaugh
Thomas Figueroa
John Beard
Carsten Schoenert
Maciej Suminski
Tomasz Włostowski
decimad
Simon Richter