The extruders dictionary has been deprecated in favour of extruderList.
Done during Turbo Testing and Tooling to reduce the number of warnings in our log.
This fixes a possible bug, too, if the extruders dictionary weren't iterated over in the order of the extruders. It would sometimes assign the profiles to the wrong extruders then. However I think the dictionary iteration in Python is in order of insertion and we probably insert them in the proper order by accident.
Done during Turbo Testing and Tooling to reduce the number of warnings in our log.
Removes another warning from the log. And it makes the code simpler in this case.
Done during Turbo Testing and Tooling to reduce the number of warnings in our log file.
This was originally added for backwards compatibility with old versions of Uranium. However the link between Cura versions and Uranium versions is already very strong (Cura crashes with old Uranium versions) so this is not necessary.
It was also adding warnings in our log that these extruders had already been added to the printer.
Done during Turbo Testing and Tooling, to clean up our log files.
Reproduction steps:
* In the Material Manager, click on 'Import material'.
* Change the file type in the file dialogue to 'All files'.
* Select any .def.json file, for example from Cura's own resources/definitions folder.
Previously this crashed the application. Now it shows the user an error message instead.
Fixes Sentry error CURA-D4.
The setting print_sequence was not being resetted to all at once
whenever the 2nd extruder was reactivated.
This commit fixes that by explicitly resetting print_sequence
when reenabling an extruder, if it has been changed by the user.
CURA-6914
The machine manager was leading to a crash when trying to enable
the second extruder in single-extrusion printers, because the check
for the second extruder was not correctly implemented. This commit
fixes that issue by checking if the global stack has the specified
extruder. If it does not, then the function returns while logging the
issue.
CURA-7048
When syncing to a different printer type only the global user changes
where kept, while the per-extruder user changes were not copied at all,
since the extruder list is empty before the new machine becomes active.
This commit fixes this problem by keeping a copy of the per-extruder
user changes before the new machine (of different type) is activated.
The copied user changes are then transfered to the new global stack
after the new machine is set as active.
CURA-6127
This should not happen, but we've seen some cases where it would cause a crash, usually
when a previous upgrade did something a bit weird (in this specific case; a printer
with an empty variant, whereas it should have a variant).
Since any change that the user will make will ensure that the variant is no longer empty (eg;
any selection of a variant will mean it's no longer empty) and that there is no way back,
it should be pretty safe to ignore the situation as it will resolve itself eventually
CURA-6992
This should not happen, but we've seen some cases where it would cause a crash, usually
when a previous upgrade did something a bit weird (in this specific case; a printer
with an empty variant, whereas it should have a variant).
Since any change that the user will make will ensure that the variant is no longer empty (eg;
any selection of a variant will mean it's no longer empty) and that there is no way back,
it should be pretty safe to ignore the situation as it will resolve itself eventually
CURA-6992
