CURA-4053
An old project file doesn't have the definition_changes container in the
stacks. When this is the case, Cura should also check if the definition
changes container in an existing stack is empty or not for project file
loading conflict detection.
CURA-4053
- In Cura 2.5, there is no definition_changes in the stack. This is now
taken into account when doing conflicts detection.
- In Cura 2.5, we have empty containers named as "empty_variant" and
such. Those are now properly handled in conflict detection.
CURA-4053
If the global stack is not found, we assume the machine is not there and
default to create a new one. If the machine is found and there is not
conflicts, then we check the extruders associated for conflicts.
CURA-4053
- Fix that if the resolve strategy is new for machine, Cura should
always create new global and extruder stacks
- Fix possible duplicated IDs when "Create New" machine is selected
CURA-4053
When loading a project file:
- Only check if the global stack exists to detect conflicts instead
of checking the global stack and the extruder stacks. It can happen
that the global stack exists while the extruder stacks not or the
other way around.
- Always assign a resolve strategy to container(s). There can be
"None" strategies and those were not handled correctly.
The overriding doesn't make any sense. The original commit mentions that it should fix something, but it doesn't acutally fix it. It seems
the original issue was fixed in the proper place, leaving this code to mess everything up.
CURA-3756
global_container_stack.definitionChanges always returns a container, global_container_stack.findContainer({"type": "definition_changes"}) does not (because an empty container does not have the type "definition_changes".
Recently we changed the empty containers such that there is only one empty container instance and it doesn't have the proper type any more. Instead we have properties on the stack that allows us to find the container with the proper type. It's faster and easier to use.
We've had a few bugs about this so I decided to update all of them to remove those for the future, except the ones in plugins/MachineSettingsAction/MachineSettingsAction.py because we have a pending pull request that fixes those. Fixing them would give merge conflicts for fieldOfView.
It doesn't really belong to CURA-4024 but I'm sticking it under that nomer anyway to get it reviewed.
