The crash was due to a null pointer thta can happens in Footprint chooser,
frame, when hit the space bar if the canvas showing the Fp has the focus.
Fixes https://gitlab.com/kicad/code/kicad/-/issues/20780
(cherry picked from commit 34e49758d0)
It is used to enter a point position and a grid origin.
The new button (only in grid origin dialog) allows reset the position.
(cherry picked from commit f8ec23db00)
If we pass a COMMIT to a posted action, the COMMIT
may no longer exist when the action is run.
Equally problematic, if another COMMIT is pushed
in between we'd probably also run into trouble.
We still allow the API to do this because we don't
have a better solution at present. But we need
one.
(cherry picked from commit 60a26308ae)
We use IN for INCH as units, but IN is defined in a Windows header
(cherry picked from commit b0fe4df3c5)
(cherry picked from commit 0acdabd1eb)
(cherry picked from commit eaa1e6d594)
Remove this hotkey from "toggle show cursor always" as this is a more
global option, not as needed (probably) in hotkeys.
Also re-arranged MD_SHIFT + MD_CTRL+ <key> to MD_CTRL + MD_SHIFT + <key>
in order to standardize and help searches in the future
Fixes https://gitlab.com/kicad/code/kicad/-/issues/19903
wxBitmapBundle assumes the smallest bitmap added is the intended "original" size for a particular use case.
And generally that is probably true. However, we re-use icons in some places where we intend for them to start at 16
or start at 24. This is problematic when GetPreferredBitmapSizeFor is called for calculations because it'll return the
16*scale number instead of 24*scale number. So let's just allow passing in a min height restriction to KiBitmapBundle
for when we reuse bitmaps.
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
ki::any is a standards-compliant implementation, based on the GCC
standard library. However, it uses type_info::hash_code() to check
the validitiy of a ki:any_cast, rather than comparing the type_info
objects directly. This comparison, used in the standard
implementations, is fragile across translation unit boundaries when
built with Clang.
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.
jean-pierre charras
Jeff Young
Jon Evans
Seth Hillbrand
Marek Roszko
John Beard
Wayne Stambaugh
Ian McInerney
JamesJCode
Mike Williams