ADDED: Horizontal/vertical zoom for simulator plots, via mouse wheel,
toolbar buttons, menu commands, and hotkeys.
ADDED: Simulator preferences panel, populated with mouse wheel
and trackpad settings that control pan and zoom of simulator plots.
ADDED: Zoom In/Out Horizontally/Vertically commands that can be bound
to hotkeys.
CHANGED: Simulator plot scroll wheel gestures are no longer hard-coded
and can now be configured via the new Simulator preferences panel.
Fixes https://gitlab.com/kicad/code/kicad/-/issues/16597
Other unreported bugs that were fixed:
- Fixed wierd, jumpy simulator plot view limiting behavior.
- Fixed Zoom In Center and Zoom Out Center commands not preserving
the simulator plot center point.
- Fixed simulator plot nudging when exported as PNGs.
- Fixed rectangular selection zoom being able to exceed simulator plot
view limits.
Notes:
- Provided new SIM_PREFERENCES struct to be used for future
simulator preferences set via the simulator preferences dialog.
- Bundled pre-existing EESCHEMA_SETTINGS::SIMULATOR settings into
EESCHEMA_SETTINGS::SIMULATOR::VIEW.
- Replaced mpWindow::EnableMouseWheelPan with more general
SetMouseWheelActions.
- Refactored and tidied up wxMathPlot's mpWindow code involved with
fitting, zooming, and panning.
- Consolidated long lists of duplicated member variable initializers to
a new mpWindow private delegated constructor.
- Provided provisional Zoom In/Out Horizontally/Vertically toolbar
icons that need improvement by a graphics designer.
- Provided gitignore entries for the Qt Creator IDE
Removes old defines and work arounds for earlier wx versions and adds a
CMake requirement to use at least 3.2 (or the minimum matching wxPython
version)
Most of these settings are now available in the appearances panel.
It was concluded in a Zulip discussion that any missing items can
be added back in time if people find they need them (ie: complain).
Also hooks up 3DViewer to the common language framework.
macOS' application menu generates command events and can't call our tool
framework directly, so we have to keep the event table handlers around
to handle these events.
Using a boolean argument just leads to a lot of trailing booleans in the
function calls and is not user friendly. Instead, introduce PostAction()
to send an action that runs after the coroutine (equivalent to passing
false or the default argument), and leave RunAction as the immediate
execution function.
We don't really control when these are called, so best not to assume
we've finished initialization of the frame/screen/document/whatever.
Possible fix for KICAD-KY.
Note that this only works where a BOARD_COMMIT or SCHEMATIC_COMMIT is used.
(BOARD_COMMIT is used almost universally in PCBNew, but SCHEMATIC_COMMIT
has very little adoption in EEschema so far.)
Temporary and autosave files do not neccessarily have the correct
permissions set to replace existing project files. This updates the
permissions to match the existing values where possible
Fixes https://gitlab.com/kicad/code/kicad/-/issues/13574
While unfortunate (we generally frown on having fixed sizes in
favour of having everything auto-layout), in this case it's a
cost of lazy-loading the panels.
Fixes https://gitlab.com/kicad/code/kicad/-/issues/14785
Don't assume the dialog is mode-less and call Destroy() from within a
dialog method. This will most assuredly crash if the dialog is shown
modally or quasi-modally.
Don't leak memory for mode-less dialogs created on the stack. Make sure
when the parent frame window is closed that all mode-less dialog memory
is cleaned up. Dialogs are not child windows like controls and toolbars
so their memory does not automatically get cleaned up when the parent
window is destroyed.
Do not directly access frame parent window's pointer in dialog destructors.
Apparently the tear down order when destroying mode-less dialogs is not
guaranteed so the parent window may get deleted before the dialog causing
a crash when accessing the parent window pointer from the dialog dtor.
Do not close mode-less dialogs in the parent frame's destructor. This
doesn't guarantee that the dialog(s) will be destroyed before the parent
but it may reduce some careless mode-less dialog event handling in the
future.