It is checked if the file data is None or empty (the upgrade is then considered 'failed'). But to unpack the file data, it needs to be a tuple.
Contributes to issue CURA-844.
The current settings in 2.1 specified a machine instance. In 2.2 they specify a machine definition. There is not enough information in one file to be able to translate that.
Contributes to issue CURA-844.
Falling back to normal.inst.cfg isn't enough. That profile may be filtered out by the machine, variant and material. We need to fall back to a different quality profile depending on the machine, variant and material.
Contributes to issue CURA-844.
Custom profiles are always quality changes. They should always say quality in the original anyway; that was an assumption we've made thousands of times.
Contributes to issue CURA-844.
We don't know the actual quality type, the quality profile that this profile is based on. Maybe there isn't one, even. As a solution we always base imported custom quality profiles on normal.
Contributes to issue CURA-844.
These profiles were not thought of as built-in. Instead, they were sorta constructed from pieces. That complex piece of code won't be necessary any more after I add this and after Cura 2.3 has proper profile inheritance again.
Contributes to issue CURA-844.
The quality profile now sometimes gets updated to a quality profile, and sometimes to a quality-changes profile, depending on whether the profile is built-in or not.
Contributes to issue CURA-2006.
This prevents a mix-up of how material names should be translated for quality profiles and how material names should be translated for material profiles.
Contributes to issue CURA-844.
One was in metadata. That is the correct one. The other is unnecessary and was being ignored, but we don't need to write it.
Contributes to issue CURA-844.
Currently it sets the user profile to 'empty', which is bad because empty is read-only. But it allows me to continue for now. I'll find a solution for that later.
Contributes to issue CURA-844.
Turns out that copy.copy() doesn't work on ConfigParsers. It returns a different instance but modifying that instance still modifies the old configs. Deep copy isn't allowed. But this dictionary copy works.
Contributes to issue CURA-844.
If the old profile didn't specify any material, it would be global. But if the new machine specifies that its profiles are material-specific, these profiles have to be split into multiple profiles in order to be able to show them in Cura 2.2.
Contributes to issue CURA-844.
Also updated the description and made it a bit more accurate. Because this concerns not only the skirt, but also the brim.
Contributes to issue CURA-1678.
They now fallback to "empty" so that it can still construct a valid
instance, albeit with a missing profile (such as material), if some
profile is missing from the original machine instance file.
Contributes to issue CURA-844.
This was required since Cura 2.1 produced files with the same filename (bar extension). This then resulted in two containers with the same ID. If you had bad luck, an instance container was chosen as global container (depending on which was first in the unordered dictionary). This gives the current settings the postfix _current_settings, fixing that issue.
Contributes to issue CURA-844.
Why there is a difference between 'general' and 'metadata', only His Noodleness knows. Also put in a default for the type. It should apparently be 'quality' unless it is a user profile.
Contributes to issue CURA-844.
I'm not quite pleased with the variant translation being inside this function, so I'll move it to VersionUpgrade21to22 soon I think.
Contributes to issue CURA-844.
A translation dictionary makes it much easier to edit the translations. Also this now just translates one printer, instead of a list.
Contributes to issue CURA-844.
This solution is a bit neater in code. It makes the function perform a single purpose, since it no longer translates a list of setting names but just one. Also it now neatly puts the translations in a separate, easy-to-modify dict. Only disadvantage is when simple key look-up is not sufficient, such as when renaming lots of settings at once, where substring matching would make the code a bit shorter. But we shouldn't do such a rename anyway.
Contributes to issue CURA-844.
It is not entirely accurate in the translated version, since the new current_settings is not machine-dependent any more. However, without information on the original file name, this is as good as it gets, since that instance profile there only mentions the machine it is dependent on in the file name.
Contributes to issue CURA-844.
