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
The action menu handler was capturing too many menuitem events.
Only context menuitem highlight events and some popup menu events need to be captured
Any id < 0 (like automatically assigned menuitem id) is no longer captured.
Fixes: lp:1831669
https://bugs.launchpad.net/kicad/+bug/1831669
The source bitmap was copied to the new created item.
However, for Checkable menu-items, when setting a bitmap, our standard check bitmap is also added.
This is unwanted when the source bitmap is the wxNullBitmap (bitmap sizes are different)
This commit redirected too many menuitem IDs to the tool manager.
Only some context menu items have to be redirected, not all inside ACTION_EVENT events.
This hack is not perfect. It needs a better handling of ACTION_EVENT handling.
Jeff Young
Seth Hillbrand
Ian McInerney
jean-pierre charras
Seth Hillbrand
Jon Evans