* cMake: Add base support for LibPack3
Minor changes to FreeCAD source code to support compiling with Qt 6.5 on MSVC,
and changes to cMake setup to support the new Libpack.
* NETGENPlugin: Fix compilation with MSVC and OCCT 7.8
* Material: Switch to Wrapped_ParseTupleAndKeywords for /fpermissive- on MSVC
* Base: Prevent accidental definition of MIN and MAX by MSVC
* cMake: Prevent accidentally finding an old LibPack
* Material: Wrap another ParseTuple call
* OCCT: Modify includes for 7.8.x
* Part: Change TNP code to use Wrapped_ParseTupleAndArgs
* Spreadsheet: Workaround for MSVC macro pollution
* Mesh: Workaround for MSVC macro pollution
* Base: Remove extra MSVC flag (moved to CMake)
* Tests: Fix compiling with /permissive-
* FEM: Fix Qt warnings about duplicate element names
* cMake: Ensure major version numbers are set
* Address review comments.
* cMake: Further tweaks for LibPack3
* cMake: Modify specification of compiler flags for MSVC
* Main: Remove QtQuick testing code
* cmake: Find Boost before SMESH (which uses it)
* Fixes for LibPack2
* cMake: Another try at importinhg VTK cleanly
* [Sketcher] Correct default OVP and Geometry Creation colors
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
---------
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
On some systems the boost-python suffix is not exactly as the code
currently expects. To avoid getting even more guessing in the CMake
files about how exactly the python component is named in the boost
installation we introduce a variable FORCE_BOOST_PY_SUFFIX that can
enforce a specific suffix. If the variable is not set the behavior is as
before.
* Core Icon Revision
Update utilities-terminal.svg
Update button_add_all.svg
pixel alignment
Pixel alignment was performed for the specified icons.
* Changes requested by Obelisk
* Return old icons
* fix selection from Sketcher Task Panel
* fix selection from 3D View
* Synchronize selection between Task Panel and 3D View
Signed-off-by: CalligaroV <vincenzo.calligaro@gmail.com>
If two straight edges were selected the chamfer distance would be recalculated so that the length of the straight segment would be equal to `r` (the radius entered by the user). But this was, and is, not done if one or both edges are arcs.
By removing the recalculation code the endpoints of the straight chamfer edge now always match the endpoints of the fillet arc that would be created for the same radius. This also matches the fillet/chamfer behavior in for example Part and Sketcher.
