The snap range needs tuning to preference and monitor resolution. This
shifts the default range down for users until the customization bits are
implemented.
This is a board file format change to account for the new properties.
Also, we now only store the critical information about the dimension's
geometry in the board, rather than storing every drawn line.
The DIMENSION object is now an abstract base, and ALIGNED_DIMENSION
is the implementation that exists today (we will add more dimension
types in the future)
You can now enable and disable snap to grid when drawing/editing across
all apps. You can also tie snap to grid to the visibility of the grid
to allow rapid enable/disable via grid display.
* Consolidate the measure tool into one tool (this gives cvpcb
unit changing and snapping capabilities in its measure tool)
* Transition cvpcb to use actions for the sketch modes
* Replumb how magnetic items settings are stored and used
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.
* 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.
Items and layers that are hidden in the view should not be used as snap
points. This happens in multiple locations:
1) Grid Helper for normal tools
2) TOOL_BASE::snapToItem for router
Resolves KiPro Issue #116
Fixes: lp:1833128
* https://bugs.launchpad.net/kicad/+bug/1833128
When moving a group of items, the allowed snapping layers should be each
layer in the group, not just the first item's LSET.
Fixes: lp:1830164
* https://bugs.launchpad.net/kicad/+bug/1830164
Choosing the drag origin should not be dependent on the snap settings in
pcbnew. Snap settings are sensible when you are designating a target
only. Additionally, when dragging a module, we do not want the
footprint's pads to be used as targets for snapping.
Fixes: lp:1814402
* https://bugs.launchpad.net/kicad/+bug/1814402
Snapping to item options were partially disconnected when unifying
framework. This re-attaches the options and adds the additional option
for graphical items.
Fixes: lp:1801377
* https://bugs.launchpad.net/kicad/+bug/1801377
Rather than selecting an arbitrary track to snap, we select the closest
track to our point, allowing the via to be placed along the full track
length.
Fixes: lp:1813324
* https://bugs.launchpad.net/kicad/+bug/1813324
When we draw a path, we usually want to close the path when clicking on
the end of another line. This uses grid helper to ensure this
progression happens as expected.
Distinguish between the snap-from and snap-to items. Previously, we
used the SELECTED or DRAGGED flags but the flagging arcitecture was
inherently fragile. This specifies items directly that should not be
used as snap targets.
Fixes: lp:1802795
* https://bugs.launchpad.net/kicad/+bug/1802795
Filtering based on selection ignores the use case where we are measuring
to a selected item. This utilizes the dragged flag to prevent snapping
based on the current state of the item drag.
Fixes: lp:1801089
* https://bugs.launchpad.net/kicad/+bug/1801089
When snapping, we should allow any point identified as a snappable
point. The additional consideration for corners might be used for
alignment in the future.
Fixes: lp:1802741
* https://bugs.launchpad.net/kicad/+bug/1802741
Disabling the grid should leave the snapping in place. But our disabler
returned the current point as closest, effectively always ensuring the
cursor position was the closest snap. This only uses grid when
requested.
When considering potential targets for snap points, we need to exclude
the currently selected item as this will mean that we always snap to
ourselves when editing an existing item.
Fixes: lp:1796507
* https://bugs.launchpad.net/kicad/+bug/1796507
This shows the snap indicator even when the item we are snapping to
occurs on a grid point, giving the user an indication that the point is
correctly connected.
Many items require precise, non-grid movement. Adding the ability to
flag a non-grid option will permit this behavior.
This is a required precursor commit to fixing lp:1738818 and lp:1771683
The computeAnchors function is used to find best drag locations for
items being moved. All movable PCB items should be handled.
Fixes: lp:1794304
* https://bugs.launchpad.net/kicad/+bug/1794304
When requesting to move a footprint based on the pad, the pad layers
should determine the snapping. This extracts layers from the selected
pad before allowing the filtering for locked pads
Fixes: lp:1787627
* https://bugs.launchpad.net/kicad/+bug/1787627
Rename GetPolyPoint() to BuildPolyPointsList(), because GetPolyPoint() looks like an accessor, but it is not an accessor.
(Using it as accessor can creates a *very long calculation time* for very basic access to polygon vertices)
Fixes: lp:1745050
https://bugs.launchpad.net/kicad/+bug/1745050
Jon Evans
Seth Hillbrand
Jeff Young
Ian McInerney
Seth Hillbrand
jean-pierre charras