macOS' application menu generates command events and can't call our tool
framework directly, so we have to keep the event table handlers around
to handle these events.
While it's a bit of an encapsulation leak (see comment in
CONNECTION_SUBGRAPH::driverName()), it more than doubles undo/redo
performance in documents with *lots* of nets.
When working in high contrast mode, we want to be able to select a
footprint with only elements in, e.g. silk and fab layers.
The previous design for footprint IsOnLayer had one behavior of every
other element and a different behavior for footprints. This leads to
multiple bugs as new features use the overloaded IsOnLayer expecting it
to report if the element exists on a layer or not.
For footprints, we need a different routine to determine whether or not
to select the footprint when clicking on it. IsOnLayer will report if
the footprint has any elements on a specific layer but we don't want to
use the bbox for a hittest because large footprints with through hole
pads will exist on every layer and have an enormous bbox. Instead, we
filter footprints based on the hittest of each element. This behaves in
a more logical fashion, allowing you to select a footprint by clicking
on a visible element of that footprint.
Fixes https://gitlab.com/kicad/code/kicad/-/issues/15284
Before, we did not actually prevent users from adding a field also named
Quantity to their symbols. This of course does not play nicely with the
assumptions that Quantity is a special column in the fields editor.
By making it a named variable, the user can safely add it to a symbol
and it will not be editable, and will also work in the fields table
editor as expected.
If KiCad crashes or exits without deleting the lockfile, don't show the
warning message unless we are not the one who locked it or there are
other KiCad instances running locally.
This should catch 99% of the cases where the message is shown
incorrectly. There may be some corner cases where the lock file is
created on a network drive using two different machines with the same
name and same user but these cases should be (famous last words)
sufficiently rare as to not be observed in practice