These two version upgraders do the same operation. Their code is copied. Instead, we can just let one version upgrader upgrade both versions of the files.
Contributes to issue CURA-7413.
Previously, the ironing_inset was changed in the profiles to reflect
the changes made in the CuraEngine. This inset though was not taking
into account the ironing_pattern (in the CuraEngine, the inset is
compensated differently depending on the pattern).
This commit fixes that in the version upgrader and the printer
definitions in order to maintain the same behavior for the old
profiles.
CURA-7318
The slicer has been adjusted to give this setting a more logical function: It should be an inset of the outer edge of ironing as it appears in layer view where the lines are made thinner according to their flow.
As a result all of the slices with ironing have changed. This adjusts the setting value so that the actual slice output will not change, just the appearance of the setting.
Contributes to issue CURA-7318.
Conflicts:
plugins/VersionUpgrade/VersionUpgrade460to462/VersionUpgrade460to462.py -> On master we removed the getCfgVersion function, while we moved the entire plug-in to a different folder in 4.6.
resources/definitions/skriware_2.def.json -> On master we merged a PR that changes more or less all settings, while on 4.6 we doubled the maximum deviation.
The code was moved to uranium, so no need to test them in a plugin.
In some cases they were also testing a specific implementation artifact and not
actual expected behavior.
CURA-7388
Took me a while to see why Cura was confusing the extruder stacks. It worked fine during the actual upgrade itself. Then later after the start-up sequence it suddenly re-wrote them wrongly.
Why is there an ID field in here? Shouldn't it just take the file name as the ID? Stupid!
With this it's starting to look like something. It's no longer giving any corruption errors now with any of my test cases. However e1 is still being set to the definition of e3 for some reason.
Turns out that the parsers apparently refer to a lot of subobjects which are crucial here, and they don't implement the normal copy well. Deepcopy it is then.
Stupid stuff. All of these containers need to be copied. It's not possible to work this out for all materials properly, since we can't read into these materials what their GUIDs and material types are.
It's a LOT more work than I thought, because the new printer has 4 extruders instead of 2. That means that files have to be copied for the other two extruders. A big hassle.
