Speculative fix, as I couldn't reproduce. But this seems like it could
cause the reported issue, though I think ~ACTIVATION_HELPER and the
callback should both be on the same event loop, so it's not clear to me
that it is exactly the issue.
And add a wxCHECK to at least bail safely before handing a nullptr off to the
later functions.
Fixes: https://gitlab.com/kicad/code/kicad/-/issues/20693
Te update didn't refresh, so the snap extensions sometimes only
appeared after the _next_ mouse move, which was annoying when the
mouse was very still (e.g. when deliberately hovering over an item).
Use a wxTimer to put all the callbacks in the UI thread which is also
much simpler. Also the update function needs to call a canvas refresh
as well as the item update.
Recommendation is to avoid using the year nomenclature as this
information is already encoded in the git repo. Avoids needing to
repeatly update.
Also updates AUTHORS.txt from current repo with contributor names
If the thread starts before the proposal tag is constructed
as nullopt, the thread can unblock and think it has a proposal.
This isn't true, so it reads junk memory and crashes.
Relates-To: https://gitlab.com/kicad/code/kicad/-/issues/18835
Pass things as unqiue_ptrs. I don't think there's that much
on the stack, but certainly addinig big enough chunks to the batches can
upset the coroutines.
Also reinstate a ClearDrawables which went AWOL.pick
Relates-To: https://gitlab.com/kicad/code/kicad/-/issues/18835
These are added to from the activation delay thread, but
accessed from the tool thread (e.g. via computeAnchors)
so they should be protected from concurrent access.
Relates-To: https://gitlab.com/kicad/code/kicad/-/issues/18835
These shouldn't be bad, and probably don't actually happen,
but they will act to clear extant construction lines for no
new shown items, so may as well be clear that they don't
do anything.
This makes it easier to control what snap points you are aiming for
without accidentally activating objects just by mousing near them
on the way to somewhere else.
This is a pretty major rework of the snapping system.
The GRID_HELPERs now have a separate CONSTRUCTION_MANAGER
which handles some of the state involving "construction
geometry".
This is fed with 'extended' geometry (e.g. "infinite" lines from
segments) for use in generating things like intersection points.
It also handles adding this geoemtry to a GAL view item
(CONSTRUCTION_GEOM) for display to the user.
The process is:
* A TOOL creates a GRID_HELPER
* Optionally, it pre-loads a "persistent" batch of construction
geometry (e.g. for an item's original position)
* The grid helper finds useful snap 'anchors' as before, including
those involving the construction items.
* Other items on the board can be 'activated' by snapping to one
of their main points. Then, if it has construction geometry,
it will be added to the display. At most 2 items of this kind of
geometry are shown, plus the original item, to reduce avoid
too much clutter.
The dashed snap lines state machine is also handled in the
CONSTRUCTION_MANAGER and displayed in the CONSTRUCTION_GEOM item.
