The previous minimum value was based on anecdotal experience about what the minimum width is that a printer can normally print. That's better as a default value and shouldn't be used as a minimum value.
The minimum value should be based on what the technical or physical limitations are. There are no real technical or physical limitations other than that you can't have 0-width lines. So the minimum is just-above-0.
Contributes to issue CURA-7682.
The setting "Enable Variable Line Widening" was using the same notion as the Print Thin Walls.
This commit fixes that by removing it and making the settings "Minimum Feature Size" and "Minimum
Wall Line Width" dependand on the Print Thin Walls.
The commit also adds reasonable default and minimum/maximum values for those two settings, along
with a clearer description on how these settings affect the thin features of the model.
CURA-7682
The buildplate meshes can be in .3mf format. When Cura is loading a printer, it may try to load
its mesh from a 3mf file. At the moment cura is starting up there is no build volume yet, so adding
a convexHull to the printer's 3mf buildplate mesh is not possible. By surrounding the addition of
the convexHull with a try-except, loading of 3mf buildplate meshes on startup doesn't cause issues.
Fixes https://github.com/Ultimaker/Cura/issues/8585
It needs to use the double brim size, as it needs to ensure that
it has enough room for it's own brim and any object brim.
The resolution of the circle is increased so that the shadow matches
more with what is actually being printed
CURA-7643
This runs a filter optimisation to choose the best PNG filters for compression, then RLE optimisation. The pixel value output is still the same, but file size somewhat smaller.
The changelog doesn't use the @-syntax for linking Github users. Removed
@-symbols in front of user names to stay consistent with previous
developer mentions.
Also rephrased the description of allow scrolling through settings-
tooltips.
One of the weirdest errors out there, and as far as I know we're the only ones suffering from it, due to having multiple packages of Python bindings created with Sip as well as having PyQt and different threads.
This obscure error happens when a module with Sip bindings is being imported after PyQt. Due to a clash with the Sip versions or something, it then fails on the custom module. Import all of our custom modules with Sip bindings first.
This is causing a crash if self._application is used before the __init__ has finished (or at least passed the definition of self._application). That can happen in this class since some functions are called asynchronously.
It would also make writing tests easier because you can mock the getInstance() function to return a mock object, and only need to monkeypatch that for the function under test rather than also for the constructor.
Fixes Sentry issue CURA-1B5.
