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.
This format is more extendable in the future, should separator and
spacer support be added to groups.
Also, this now has a working UI for modifying the toolbars.
* Manage the settings using the settings manager for better lifetimes
* Better architect the internals and JSON to make it easier to identify
the various tool types
Added m_signalsGrid context menu entries, Create a new cursor from every cell but Delete only from Cursor 3 and above
New entries are saved into their *.wbk files. Loading of current files should not be affected, as tested,
and on save they get the new property added.
Updates *.wbk file version to "7".
If the tab has more cursors than the loaded file, extra cursors should not be affected, otherwise new cursors shown up.
CursorD left hopefully untouched and kept the legacy behavior close to Cursors 1 & 2.
No more known bugs. It is now working as expected as tested on win11 and Debian 12.
m_cursorsGrid events also work.
Fixes: https://gitlab.com/kicad/code/kicad/-/issues/15211
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
