This looks like it was always intended for macOS but was accidentally changed for Windows as well.
If this is a requirement on windows, I'm sure theres better ways to fix it....
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.
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
Iterating over the tool stack, we potentially remove the current
iterator. If this removal happens at the beginning of the toolstack, we
cannot decrement the iterator to a position before the stack without
creating an invalid state.
It belongs out in the calling loop so that if someone else uses
finishTool() later they won't get bit by it.
This also fixes a crash bug where we weren't deactivating all tools
because we couldn't back up at the beginning of the stack (and the
loop increment therefore went past the first element).
Fixes https://gitlab.com/kicad/code/kicad/issues/4206
The immediate action option clears (or not) the position of the events.
We use this to determine if the command should start at the given
position or merely activate the tool. This was being checked in the
menu options, which only activated for tool commands in the context
menu. Moving to the process event, we catch hotkeys as well.
This also restores the previous logic in eeschema that used a static
variable for storing wires rather than the private class variable.
Starting the draw event now picks up from the existing wires when
activated in immediate mode.
Fixes#3891 | https://gitlab.com/kicad/code/kicad/issues/3891
* 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.
Re-arranging the stack will invalidate the iterator that is removed and
inserted (begin()). Because this is not a threaded operation, we can
only do it to ourselves, so check that the operation isn't a NOP before
performing.
Fixes: lp:1832930
* https://bugs.launchpad.net/kicad/+bug/1832930
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.
This removes the remaining hard-coded segments counts and replaces them
with the relative error calculation where the segments per arc is
determined by the maximum error we allow (smaller arcs = fewer segments)
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.
Jeff Young
Mark Roszko
Jon Evans
Ian McInerney
Seth Hillbrand
Tomasz Wlostowski
jean-pierre charras
Thomas Figueroa
Seth Hillbrand
Simon Richter
Maciej Suminski