We're creating the variable but then requesting the 0th element from the list each time... That can be more logical and more efficient.
Contributes to issue CURA-4243.
CURA-4348
- If no project is loaded beforehand and then a model file is loaded,
the job name should be determined with the current machine name and
the first loaded model name.
- If a project is loaded, the job name should be the same as the project
name, and it should not change until another project is loaded.
It would try to override extruders that weren't thare. This was caused by the previous
change that would always load the extruders, but that should only happen for new machines, not for
overrides.
CURA-4204
When a new material is created during project file loading, the material
for each stack is set according to the parent material ID, but actually
the child material should be used. This fix uses a hack to find the
corresponding child material for a stack so when a user chooses to
create a new material during project file loading, the material can be
correctly set.
CURA-4107
In old Cura, there is no definitionChanges container, so loading a
project file from an old version will result in stacks with empty
defnitionChanges. This will cause an unnecessary auto-slice problem when
we switch between the extruder tabs for the first time. This action will
trigger a piece code in MachineAction which creates a definitionChanges
container for the active stack if it is empty. This eventually triggers
a propertyChanged signal and results in an unncessary auto-slicing.
CURA-4167
Custom FDM printers have multiple extruder stacks by default but not all
of them may be used. The actual number of extruders depends on what's
defined in the global stack. Because in the current architecture,
single-extrusion machines don't have extruder stacks, in project
loading, the extruder count in the global stack should be used so these
cases can be handled properly.
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
Except when we fill the instancecontainer via deserialising. Because then we want to retain the original version number.
Contributes to issue CURA-3427.
