fp viewer uses the default colors, because it has no color setup dialog.
class_colors_design_settings: remove not used members.
Fix issue in modedit: the color config was never read.
Before the change, the plugins had to be installed to one of the default
search paths, but it should not be necessary for developers working on
3D viewer plugins.
This was due to a missing initialization of the dummy board color settings (used to draw the footprint in the 3D view).
Fixes: lp:1708712
https://bugs.launchpad.net/kicad/+bug/1708712
- support for background color setting
- removed several global config settings (such as g_Drc_On)
- wrapped most of global config settings in PCB_GENERAL_SETTINGS class
- reorganized PCB general options dialog to clearly mark which options concern only the legacy canvas
- new GAL feature for legacy users: double-click (or E) to change track width available as an option.
Fixes: lp:1530543
* https://bugs.launchpad.net/kicad/+bug/1530543
Fixes: lp:1707145
* https://bugs.launchpad.net/kicad/+bug/1707145
Using -O3 is default for release builds with gcc/clang anyway, so this
doesn't gain anything, but overwriting the existing flags might remove some
that might be needed.
eeschema now supports arbitrary colors for all object types, and
pcbnew does in GAL canvas. When switching from GAL to legacy canvas,
pcbnew will convert colors to the nearest legacy color.
bitmaps.h was included in nearly every file in the project due to it
being included by base_struct.h
Only about 130 files actually use the XPM definitions defined there, and
many of those already included bitmaps.h themselves, or via
menu_helpers.h. However, touching bitmaps.h would result in over 400
rebuilt files for pcbnew alone.
This commit moves the bitmap-related types like BITMAT_DEF out to a new
header, which is still included by base_struct.h, which is less
avoidable for now, it's it's used in the interface.
The icon list is still in bitmaps.h. This has the side effect that's
it's now easier to automatically generate this file.
Many classes in pcbnew and eeschema needed some functions moved
to the implementaitons from the headers too.
There is no need to use mm_malloc at this moment. Explanation:
1) It was planned that there was advantadge to use aligned memory but it
was not measured the performance. 2) aligned memory is needed for use
with SIMD (i.e: SSE) but that is not used at moment.
Fixes: lp:1626278
https://bugs.launchpad.net/kicad/+bug/1626278
Marvin Schmidt
jean-pierre charras
Tomasz Włostowski
Baranovskiy Konstantin
Maciej Suminski
Wayne Stambaugh
Kristoffer Ödmark
Simon Richter
Fabrizio Tappero
Cirilo Bernardo
Jon Evans
Kevin Cozens
John Beard
Mario Luzeiro