The tools were being set as idle, whenever an event handler execution
finished (via TOOL_MANAGER::finishTool()). Such approach does not take
into account cases when a tool is active and receives an event causing
another event handler of the same tool to run. When this happend, the
tool has been incorrectly set as idle when the second handler finished
its execution.
In a particular case, invoking the router settings dialog caused the PNS
router to be incorrectly detected as inactive in
EDIT_TOOL::invokeInlineRouter(). Due to that, ROUTER_TOOL::CanInlineDrag()
requested a selection that required disambiguation menu for items
that were modified by the router, but not yet committed. After the drag
tool had finished, the disambiguation menu was eventually shown
with items existing only in the undo buffer. Removing such item lead to
track DLIST corruption, effectively erasing all tracks.
Fixes: lp:1767826
* https://bugs.launchpad.net/kicad/+bug/1767826
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
It affected just started tools that did not have cursor settings
stored, so could not be reverted after the context menu is gone.
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
The OSX implementation needs to be poked to update the
brightening / unbrightening during running of the
disambiguation menu. (FWIW, now that I've finally seen
it in action, it's a REALLY cool feature.)
Fixes: lp:1715440
* https://bugs.launchpad.net/kicad/+bug/1715440
- 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
get_value_or() is considered deprecated, but still works in the newest
boost (1.63). On the other hand, value_or() is not available in some
versions that are still used by major distros.
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.
Message type is a kind of notification, so it should be received by all
interested tools. It used to be like that in the past, but has been
broken recently.
When creating a copy of CONTEXT_MENU, always a CONTEXT_MENU instance was
constructed, whereas an inherited type should be used. Solved with
CONTEXT_MENU::create() that has to be overridden in inheriting classes.
Event & update handlers are now virtual functions, instead of setting
the handlers with Set{Event,Update}Handler().
There used to be a number of TOOL_ACTIONs that had entries both in
SetTransitions() and the event loop, which seemed redundant and
troublesome.
Now it is not necessary anymore, transitions setup is enough to execute
associated actions.
jean-pierre charras
Maciej Suminski
Jeff Young
Jon Evans
Simon Richter
Tomasz Włostowski
decimad