CURA-5045
- If a container cannot be deserialized in project loading, it should fail
right on the spot because even if it continues, it still won't work.
- In other places, at least log deserialization errors if any of them show
up.
Only the deserialize() functions themselves may pass the ContainerFormatError on, because their callers will have to handle those errors anyway.
Contributes to issue CURA-5045.
Need to distinguish between quality and quality_changes in the cura directory,
so we need to move all custom quality profiles into the quality_changes directory.
Some gcode has its quality definition set to, say, UM2 extended, which is _actually_ just UM2 gcode. Thus, we check if the definition in the profile matches the current machine or what it in theory should be, either one being valid. See comments in code for details.
CIRA-4946
If a gcode is sliced with default profiles, there won't be any custom
profiles to import from that gcode. In that case, we show a info message
telling the user about this instead of showing an error message.
quality definition if the printer has_machine_quality. Otherwise the
fdmprinter definition must be used as a fallback. If there is no
quality_definition then the printer definition is use.
parsing, the quality definition is taken into account instead of the
definition.
The message when importing a profile to a different machine,
now shows the expected machine and the current machine definition id.!!
CURA-4839
- Add newly created quality_changes container to ContainerRegistry
- If an extruder is created by CuraContainerRegistry, in project
loading, do not try to override extruder's quality changes.
In the current fix, the quality changes that are applicable to the
machine may not have been fixed yet because they are not active at that
moment. This commit makes sure that for a single extrusion machine which
has just been updated to have an ExtruderStack, all the quality changes
containers that are applicable to this machine will be updated as well.
