key in the multi-material painting gizmo.
Fixed also a similar issue in support and seam gizmos where an object was displayed with the wrong color after pressing the ESC key.
sets of optional boolean parameters, the cut function "keep upper",
"keep lower" and "flip lower" boolean parameters were converted into
a single type safe enum_bitmask. Such a coding style is certainly
wordier than the original code, but much safer and more readable
than the error prone "boolean, boolean, boolean" function call
parameter list.
config bundles, project files (3MFs, AMFs). When loading these files,
the caller may decide whether to substitute some of the configuration
values the current PrusaSlicer version does not understand with
some reasonable default value, and whether to report it. If substitution
is disabled, an exception is being thrown as before this commit.
If substitution is enabled, list of substitutions is returned by the
API to be presented to the user. This allows us to introduce for example
new firmware flavor key in PrusaSlicer 2.4 while letting PrusaSlicer
2.3.2 to fall back to some default and to report it to the user.
When slicing from command line, substutions are performed by default
and reported into the console, however substitutions may be either
disabled or made silent with the new "config-compatibility" command
line option.
Substitute enums and bools only. Allow booleans to be parsed as
true: "1", "enabled", "on" case insensitive
false: "0", "disabled", "off" case insensitive
This will allow us in the future for example to switch the draft_shield
boolean to an enum with the following values: "disabled" / "enabled" / "limited".
Added "enum_bitmask.hpp" - support for type safe sets of options.
See for example PresetBundle::load_configbundle(...
LoadConfigBundleAttributes flags) for an example of intended usage.
WIP: GUI for reporting the list of config substitutions needs to be
implemented by @YuSanka.
notification with some locales, we don't want PrusaSlicer 2.3.0/2.3.1
to show this notification. On the other hand, we would like PrusaSlicer
2.3.2 to show an update notification of the upcoming PrusaSlicer 2.4.0.
Thus we will let PrusaSlicer 2.3.2 and couple of follow-up versions
to download the version number from an alternate file until
the PrusaSlicer 2.3.0/2.3.1 are phased out, then we will revert to
the original name.
that configuration could be recovered in the case PrusaSlicer.ini
is corrupted during saving. The config is first written into a temp file
marked with a MD5 checksum. Once the file is saved, it is
copied to a backup file first, then moved to PrusaSlicer.ini.
When loading PrusaSlicer.ini fails, the backup file will be loaded
instead, however only if its MD5 checksum is valid.
The following "Fixes" comments are for github triggers. We implemented
a workaround, not a fix, we don't actually know how the data corruption
happens and why. Most likely the "Move file" Windows API is not atomic
and if PrusaSlicer crashes on another thread while moving the file,
PrusaSlicer.ini will only be partially saved, with the rest of the file
filled with nulls. We did not "fix" the issue, we just hope that our
workaround will help in majority of cases.
Fixes prusaslicer wont open 2.3 windows 10 #5812
Fixes Won't Open - Windows 10 #4915
Fixes PrusaSlicer Crashes upon opening with "'=' character not found in
line error" #2438
Fixes Fails to open on blank slic3r.ini %user%\AppData\Roaming\Slic3rPE
Quite some time ago, many of the TBB components were deprecated in favor
of their near-equivalents in the STL or, in the case of task_scheduler_init,
were broken up and reconstituted under a less ad-hoc logic. Every time a header
file marked deprecated gets included, a rather loud warning is emitted, which
leads to a complete TBB's domination over the stderr stream during build time,
making it harder to notice _legitimate_ warnings.
Instead of merely muting the output with TBB_SUPPRESS_DEPRECATED_MESSAGES,
perform a genuine migration away from the deprecated components with the added
benefit of achieving a source compatibility with oneTBB, the successor to TBB
which has dropped the deprecated API for good.
What got replaced for what?
| Deprecated | Replacement |
| ------------------------------------- | --------------------------------------------- |
| `tbb::atomic` | `std::atomic` |
| `tbb::mutex` | `std::mutex` |
| `tbb::mutex::scoped_lock` | `std::scoped_lock<std::mutex>` |
| `tbb::mutex::scoped_lock` (empty) | `std::unique_lock<std::mutex>` (deferred) |
| `tbb::task_scheduler_init` | `tbb::global_control` |
| `tbb::this_thread` | `std::this_thread` |
Signed-off-by: Roman Beranek <roman.beranek@prusa3d.com>
../src/libslic3r/QuadricEdgeCollapse.cpp:110:39: warning: suggest parentheses around '&&' within '||' [-Wparentheses]
../src/libslic3r/QuadricEdgeCollapse.cpp:394:38: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
../src/libslic3r/QuadricEdgeCollapse.cpp:395:38: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
../src/libslic3r/QuadricEdgeCollapse.cpp:514:26: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
../src/libslic3r/QuadricEdgeCollapse.cpp:514:42: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
structured exceptions (hard crashes, segmentation faults...),
converts them to Slic3r::HardCrash exceptions and displays the exception
using the usual PrusaSlicer way.
The SEH handler is installed on the main background slicing thread
as of now, therefore hard crashes in TBB worker threads are not handled.
