There is a fallback mechanism here designed to catch cases
where a hotkey is bound to a key that needs Shift to be
input (e.g. ? requires Shift on many non-US keyboards,
but the hotkey for that should be '?', not 'Shift+/'). For any key
where the two options are equally-valid "main" key (e.g. '6' and '^'
or '?' and '/' or ':' amd ';'), this is correct, as it allows
the hotkey to be simply the character in question.
Letters don't require this treatment - using this fallback
in the letter case means that a hotkey bound to 'B' will
also fire when 'Shift+B' is pressed, even when Shift+B is
bound to something else. In fact, it could even preempt the
real Shift+B hotkey.
Fixes: https://gitlab.com/kicad/code/kicad/-/issues/19093
This means that an early return or an exception between
a manual Push/Pop (or an omission of the Pop) cannot
corrupt the layer stack.
It also means the GAL doesn't have to maintain its own
stack (with the in-scope GAL_SCOPED_ATTRS taking that role).
Reomve the Push/PopDepth functions, as they're only ever
used in pairs, and doing it manually needs more care.
For segment, circle, beziers, these are the same in all editors and only
need access to the EDA_SHAPE nature, so we can remove the duplication
entirely.
For TABLECELLs, while the cells are polymorphic in that PCB and SCH
cells are both EDA_SHAPEs (via the TEXTBOXes), the parent TABLES
are not polymorphic, and thus the implementation can't be trivially
de-duplicated. Rather than do something with templates, just keep
it simple for now and maybe look at unifying tables later on.
Make sure not to handle wheel events with 0 or 1 modifiers -
those are for the view handler, not the tool framework. We
can't rely on WX_VIEW_CONTROLS to run first, it's not always
used, for example in the 3D Viewer.
Fixes: https://gitlab.com/kicad/code/kicad/-/issues/19026
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
Implemented as handling un-consumed scroll events that the
WX_VIEW_CONTROLS doesn't want because it has too many mods
set. Then dispatch these as TA_MOUSE_WHEEL events.
The default action from the selection tools is to run the
'increment' ACTION, which is implemented differently in the
various tools: eeschema can increment labels, symedit
does pin names and numbers, and fpedit does pad numbers.
These are context sensitive actions that increment "something"
about the selected item.
A generic 'increment' action can be produced, e.g. by other tools
or UI events, which has in increment step (positive or negative)
and an 'index' which determines what about the item should be
incremented - it's up to the increment action handler to decide
what that means.
And then add a primary and secondary inc/decrement action,
which allows to bind hotkeys to each.
Bind these to:
* Sym edit: increment pin names/number
increment text items
* Sch edit: increment lables and text
* FP/PCB: increment pin numbers
increment text items
This is useful when you want to copy text content out to some
external program (or put it in a text item/box).
I'm not sure it's possible to intuit exactly what a user wants,
as you will often want to copy items as the real items, and sometimes
as text. While KiCad might be able to make a smart guess, external
programs will have no chance!
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.
Some shapes, like arcs and beziers have "lines" that
can be useful to see when editing, but aren't directly
editable and may not overlap the object's own lines.
So make it possible to, indepedently:
- Turn off the centre-point drag handle affordance
- Show the actual line segment on screen.
When working near snap anchors, which come and go
rapidly, it's often useful to see what snaps have been
calculated. Add an advanced config to show these
(EnableSnapAnchorsDebug) on an overlay layer.
With more polish this could be a hotkey or something.
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.
Also fixes grammar and capitalisation in a few tooltips.
Also standardises some terminology, such as
"Add" vs "Draw"/"Place" and "Assignment" vs "Association".
Fixes https://gitlab.com/kicad/code/kicad/-/issues/17694
TOOL_MENU::m_menu was unconditionally created by the TOOL_INTERACTIVE constructor, resulting in crashes if
we wanted to run the TOOLs in headless mode, e.g. in unit tests. This commits makes
the creation of the menu object dependent on Pgm::IsGui().
Schematics, symbols, boards and footprints all get the ability to store
files inside their file structures. File lookups now have a
kicad-embed:// URI to allow various parts of KiCad to refer to files
stored in this manner.
kicad-embed://datasheet.pdf references the file named "datasheet.pdf"
embedded in the document. Embeds are allowed in schematics, boards,
symbols and footprints. Currently supported embeddings are Datasheets,
3D Models and drawingsheets
Fixes https://gitlab.com/kicad/code/kicad/-/issues/6918
Fixes https://gitlab.com/kicad/code/kicad/-/issues/2376
Fixes https://gitlab.com/kicad/code/kicad/-/issues/17827
This reverts commit e914c0c1a073ef9f221ee0cbb3384acefffe5159
(cherry picked from commit 6b7b6fa3e3960aeec405880a47f4c4f2330e872b)
Co-authored-by: Mark Roszko <mark.roszko@gmail.com>
