The user doesn't know what a global stack is. This is a message that more clearly specifies what is really happening as far as the user can see.
The global stack may be None if this code is executed while there is no active printer. Normally the only time there is no active printer is:
- during first launch, while in the welcome screen
- during start-up until the profiles have been loaded
- if there was a profile corruption of some kind with the active printer.
So this function should not get called during those times. It probably isn't called except for the last case (in which case it's acceptable I guess).
This change is made after a request from a translator what the hell this means.
Contributes to issue CURA-7783.
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.
The addMachineExtruders function assumes that this is a new printer (first time the printer is activated since a restart of Cura) and it needs to add the extruder stacks to it. However most of the time when we're switching, it's not to a new printer. If it's not a new printer, this function would get called anyway and we'd be adding the extruders multiple times. This then does a lot of unnecessary work and eventually fails a couple of calls deep.
This change prevents it from adding the extruders if there are already extruders associated with the printer, thus preventing this unnecessary work (switch is faster) and preventing the error from happening.
Discovered during work on CURA-7501.
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.
