ADDED: Make middle mouse button double click do a 'Zoom to Fit'
in Eeschema, Pcbnew, and Gerbview. Ctrl-MMB does a 'Zoom to Objects'
in Eeschema.
Fixes https://gitlab.com/kicad/code/kicad/issues/1988
You can now enable and disable snap to grid when drawing/editing across
all apps. You can also tie snap to grid to the visibility of the grid
to allow rapid enable/disable via grid display.
Adds the ability to flip (mirror) the display, just like "Flip
Board View" does in Pcbnew.
Also added this to vertical toolbar since it's handy to not
have to go into the menu system to flip the display back and
forth.
Fixes issue https://gitlab.com/kicad/code/kicad/-/issues/2501
You can now choose the behavior of dragging with the
middle and right mouse buttons.
You can also choose which modifier keys to use for
panning and zooming with the scroll wheel or trackpad.
You can also customize the zoom speed, which makes
it possible to have a good zoom experience on a wider
range of input devices.
You can also now zoom by dragging with the right or
middle button if desired.
Fixes https://gitlab.com/kicad/code/kicad/-/issues/3885
Fixes https://gitlab.com/kicad/code/kicad/-/issues/4348
The pointer passing for display options is deprecated. This removes the
excess casting as the EDA_FRAME didn't need the base call with no value.
All requests for display options are now returned const and are updated
with a Set() routine after modification.
In Gerbview, this resolves an issue where the display options were not
stored because it was receiving the NULL from EDA_FRAME.
Just picking the next layer will be overwritten when we have multiple
objects on the same layer in gerbview. Move the selection to the top to
ensure it is out top-most layer when drawing.
Fixes: lp:1833868
* https://bugs.launchpad.net/kicad/+bug/1833868
The problem is that wxEVT_CHAR_HOOK doesn’t do the key translation
properly. wxEVT_CHAR does, but we only get to that if we skip the
event at the end of the tool’s event processing loop, which most tools
don’t do. (Selection tools, point editors, pickers, and a couple of
others do skip, which is probably why this didn’t get reported earlier.)
I played around with a couple of ways to fix wxEVT_CHAR_HOOK. Most of
them don’t work, and the few egregious hacks I tried weren't cross-
platform.
So I’m changing it so that most tools now skip at the end of their
event loops. I left out a couple that I felt were high risk (length
tuning, for instance). But there’s still enough risk that I’m 100%
sure it will break something, I just haven’t a clue what.
Fixes: lp:1836903
* https://bugs.launchpad.net/kicad/+bug/1836903
Includes the addition of an onSetCursor() handler which must be called
from both the GAL canvas AND the GAL backend (at least on OSX) to prevent
cursor flickering between (for instance) pencil and arrow.
Also includes new architecture for point editors which allows them to
coordiate cursors with the editing tools (so we can switch to an arrow
when over a point).
We were running into various corner conditions where a tool's event
loop would exit while the tool was still active, or the tool would
get popped while we were still in the event loop. (A lot of these
had to do with the POINT_EDITOR's, but not all of them.)
The new architecture:
1) tools always do a Push()/Pop()
2) everyone is responsible for their own pops; no more stack-clearing
on a cancel
3) CancelInteractive events go to all tools to facilitate (2)
It's a bit of a hack because they're statically initialized and
so we can't make use of the _() macro. We do still want it in the
code, however, because the string harvesting is based off of it.
Fixes: lp:1833000
* https://bugs.launchpad.net/kicad/+bug/1833000
If a tool called something like clearSelection while processing a
MOUSE_CLICK, the SELECTION_TOOL will pass the clearSelection
COMMAND_EVENT because it handles it as a transition, not as an
event. Because m_passEvent is effectively global, the tool manager
would then interpret that as passing the MOUSE_CLICK and we'd end
up processing the click by multiple tools.
It was confusing that the primary frames registered their tools
differently than the other frames. In addition, since the other
frames also added their own tools, foo_actions::RegisterAllTools()
didn't really register all tool but rather those used by the
principal frame (PCB_EDIT_FRAME, SCH_EDIT_FRAME, etc.)