These can happen when a tool is active that sends signals when exiting
(e.g. deselectEvent). These may be caught by the active loop in another
tool which might try to update the UI after it has been freed. By
marking all tools as "shutdown", the only event returned to them should
be null. As an extra precaution, we flag the shutdown globally within
the tool manager and check this flag before launching either events or
new tools
Fixes https://gitlab.com/kicad/code/kicad/issues/10698
(cherry picked from commit db4f2d9dd8)
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
Copy to clipboard save items (using S expr description) using wide strings
(not UTF8 encoding).
But Paste from clipboard was not converting the wide string to UTF8 string
when getting the stored data to send it as std::string to the S expr reader.
Fixes#6449https://gitlab.com/kicad/code/kicad/issues/6449
Previously, init order depended on the ordering of the
tool state map, which is opaque from the point of view of
registration. This makes it challenging to make one tool's
init depend on another. With this change, registration
order defines init order.
When invoking "Break Track" from the RMB context menu, Pcbnew
gets and uses the current position of the mouse to figure out where to
break the track. The problem is that the mouse has to be moved to select
the "Break Track" menu item, and the mouse position used is wrong. This
can result in the break in the wrong location or not happening at all.
CHANGED: This commit determines if the "Break Track" was invoked from a
context menu or a hotkey. If a hotkey, it uses the current mosue position.
If a context menu, it uses the original postion of the mouse when the menu
was opened.
There was a regression in v6 where the zoom to selection toolbar
item wasn't canceling the tool when pressed and the tool was active
(it was in v5). This implements a more generic framework for canceling
tools on button presses.
Fixes https://gitlab.com/kicad/code/kicad/issues/5103
* 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
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.
Delete the copy ctor and assignment operator to start with, but
even then the separate apps each have their own statically allocated
copy of the common actions. So we need to update all of them, which
also means having the kicad manager frame's set of actions on hand).
This changelist also adds a Clear Hotkey Assignment function since
the hotkeys set is now likely to be sparse with respect to the
actions.
All calls to {save,apply}ViewControls() have been replaced with a new
method: setActiveState(). The advantage is that setActiveState() always
saves view controls settings to the tool that set them. As long
as setActiveState() is called every time there is a tool context
switch, the changes are kept up-to-date.
Fixes: lp:1748613
* https://bugs.launchpad.net/kicad/+bug/1748613
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
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
- added TOOL_INTERACTIVE::resetTransitions()
- made protected and moved TOOL_BASE::setTransitions() to TOOL_INTERACTIVE
- TOOL_MANAGER calls TOOL_INTERACTIVE::resetTransitions() instead of
setTransitions()
This is the right implementation of the commit b25ded4d.
Previously if there were tools launched from another tool,
the settings could be stored in a wrong TOOL_STATE object.
There are times, when TOOL_MANAGER has to force cursor position
to make tools work as expected (e.g. when popping up a menu,
so tools get the right click position instead of current position
pointing to an entry in the menu).
If another tool is invoked, VIEW_CONTROLS settings have to be stored
in the TOOL_STATE object. In such case, it is necessary to revert the
force cursor setting when saving VIEW_CONTROLS settings.
Fixes: lp:1668712
* https://bugs.launchpad.net/kicad/+bug/1668712
dispatchContextMenu() stores the cursor position before displaying a
menu, so the tools use the original cursor position when processing
events (instead of the mouse position pointing to a menu entry). Later,
the previous position has to be restored, but if in the meantime the
tool was cancelled - previous settings were restored to a wrong tool.
Seth Hillbrand
Ian McInerney
Dominik Wernberger
Marek Roszko
Jeff Young
Wayne Stambaugh
jean-pierre charras
Jon Evans
PJM
Maciej Suminski
Carsten Schoenert
Tomasz Włostowski