This isn't the best possible UX (having the various modes immediately
available as graphical affordances would be best). But it's somewhat
discoverable, and at least shows the hotkey, if any, and it in the
context menu and not hidden in a toolbar right click menu. So if the
affordance-type system doesn't make it for v10, this will at least
provide something in eeschema.
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
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.
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.
This adds the concept of editing _other_ items to the one
that informs the POINT_EDIT_BEHAVIOR - in this case connected
lines. This is one of the motivations behind this system,
as it will allow to bring similar logic to Pcbnew.
This introduces the POINT_EDITOR_BEHAVIOR class, which
allows a "behavior" to be defined, which covers the creation
of edit points, updating the points on edit, and pushing the
edited points back into the object.
This keeps the logic for a single item "type" (e.g. a SEGMENT
or TEXTBOX, etc) in one place, rather than fragmneted throughout
the POINT_EDITOR class, where the invariants like point count
are difficult to keep track of as the TOOL progresses.
For now, it's implemented as an optional class, just for SEGMENT
and other tpyes work as before. Adding new types is then a
"pin-compatible" drop-in process.
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 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
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.
This allows to see what the current snap point is, which is useful when
zoomed in, or the point is like the corner of a rounded pad where it's
"in free space" and might not be immediately obvious.
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().
John Beard