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
CHANGED: Settings are now stored in versioned sub-directories
ADDED: First-run dialog for migrating settings from a previous version
CHANGED: Settings are now stored as JSON files instead of wxConfig-style INI files
CHANGED: Color settings are now all stored in a separate settings file
CHANGED: The symbol editor and footprint editor now have their own settings files
CHANGED: Color settings are no longer exposed through BOARD object
CHANGED: Page layout editor now uses Eeschema's color scheme
Settings are now managed through a central SETTINGS_MANAGER held by PGM_BASE.
Existing settings will be migrated from the wxConfig format on first run of each application.
Per-application settings are now stored in one class for each application.
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
ADDED: Back annotation algorithm,
eeschema back annotation dialog
CHANGED: added some minor helper methods to SCH_REFERENCE_LIST and SCH_REFERENCE,
split SCH_REFERENCE_LIST::CheckAnnotation on 2 parts to reuse code
* Split up the thirdparty code into the thirdparty folder (#3637)
* Create a new kimath static library containing all the math functions
This is part of cleaning the build system for #1906.
* 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
* Push a function into CONDITIONAL_MENU that adds the item
* Modify the tooltip for close and exit items to have the
program name
Fixes: lp:1835454
* https://bugs.launchpad.net/kicad/+bug/1835454
There seems to be a bug with certain GTK setups that prevents the
submenus from getting sized correctly unless the elements are added
when the main menu is displayed.
Fixes: lp:1835460
* https://bugs.launchpad.net/kicad/+bug/1835460
m_toolMgr->ProcessEvent() returns false when a ESC key is handled. It should return true.
So we force the handled flag to true for a ESC key event to avoid skipping this event.
Otherwise the ESC key event is handled twice.
At the beginning of tool dispatcher, the ProcessEvent did not return the fact a key event was captured or not.
Now this is the case, and the old char event filtering was no longer correctly working,
and some events were not fired, especially on Windows.
I'm not sure these are necessary but I got a crash when checking one
as a boolean instead of calling is_initialized(). Sadly, my debugger
doesn't like boost, so I didn't get much more info.
Includes the addition of an onSetCursor() handler which must be called
from both the GAL canvas AND the GAL backend (at least on OSX) to prevent
cursor flickering between (for instance) pencil and arrow.
Also includes new architecture for point editors which allows them to
coordiate cursors with the editing tools (so we can switch to an arrow
when over a point).
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)
Now that our tool framework handles the hotkeys, we need to skip the
passed handling work-around for actions that are already handled in the
event.
Fixes: lp:1832604
* https://bugs.launchpad.net/kicad/+bug/1832604
It's a bit of a hack because they're statically initialized and
so we can't make use of the _() macro. We do still want it in the
code, however, because the string harvesting is based off of it.
Fixes: lp:1833000
* https://bugs.launchpad.net/kicad/+bug/1833000
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.
We prevent the creation of invalid polygons by keeping the converging
lines from intersecting. This test doesn't make sense for triangular
polygons as they always intersect and we want to allow them to move
outside of the singular point.
Fixes: lp:1831481
* https://bugs.launchpad.net/kicad/+bug/1831481
(cherry picked from commit 966173c129)
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.
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)
Add the N/Shift+N hotkeys to the eeschema hotkey file.
Also adjust the COMMON_TOOLS::GridNext/Prev to work when
the screen's grid definitions do not have consecutive command
IDs (they do not in eeschema).
This is related to lp:1811018 (but doesn't constitute a fix).
* https://bugs.launchpad.net/kicad/+bug/1811018
Ian McInerney
Jeff Young
jean-pierre charras
Tomasz Wlostowski
Jon Evans
Seth Hillbrand
Alexander Shuklin
Mark Roszko
Ian McInerney
Seth Hillbrand
Michael Kavanagh
Thomas Figueroa
John Beard