CURA-3975
GlobalStack has metadata type "machine", which is different from what is
registered in the VersionUpgradeManager "machine_stack". This commit
makes sure that Cura can find the correct upgrade route for the
GlobalStack files.
CURA-3975
The upgrade for machine and extruder stacks and the preferences files
don't work because the current version registering doesn't take into
account the 1000000 multiplier and the settings_version.
CURA-3975
Rename quality profiles with name "Not Supported" to have actual quality
names. Note that the "Not Supported" only ones are renamed to "Fast_Print".
Firstly, all the resolveOrValue calls are identity functions now so they can be phased out.
Secondly, all the max(extruderValues(...)) should be done by the resolve property rather than the value property. The resolve property already makes sure that the prime tower is evenly thick for every extruder, so it doesn't need to ensure this in the value function as well.
Contributes to issue CURA-3521.
This reverts commit 319559740dd8c8c2f9ffad637bee43cef9345073.
This was already fixed (line 734 inveted it). This code breaks it when there is no extruder
Objects that aren't printed, such as infill meshes, can simply be sent to the slicer regardless of whether they are inside or outside the build volume, because they don't generate g-code in their own volume. This way you can have a model that is partially outside the build volume that still does its anti-overhang task or whatever.
Contributes to issue CURA-3951.
Instead of the metadata entry, which was a previous implementation of the function. This is essentially just an update of the test.
Contributes to issue CURA-2822.
The approximate diameter needs to be in a static field because the list model filters on that field. The filter function is not clever enough to be able to filter on values being in some kind of range or rounded, so instead the decision was made that the rounded value needs to be set in a separate field so that the static filter can filter on it.
Contributes to issue CURA-2822.
It doesn't give a problem right now since we're only iterating over lists of length 1 here, but in the future this could cause weird bugs.
Contributes to issue CURA-2822.
Properties is a dictionary inside the metadata dictionary. If you change one of the properties, it'll check afterwards if the dictionary is different from what it was before, but since the dictionary is passed by reference all the time, it'll think that the dictionary didn't change: The reference is still the same, so the thing it checks against is updated along.
This solution is a bit ugly but it does notice when the metadata changed inside the properties and then emits a change signal.
Contributes to issue CURA-2822.