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.
Two big things had to happen for this: The resource types of quality and machine stack have to be defined before the initialisation of the version upgrade manager, since the version upgrade manager needs to know those storage locations at initialisation. But the storage location is still prefaced with '.config/UM' at this point, so instead we pass on the resource type (but the resource type still has to be defined before the init).
The other big change is that we now have to name the configuration type 'quality' and 'machine_stack' instead of 'instance_container' and 'container_stack' to coincide with the resource type. This allows us to be more consistent in later plug-ins when we also have to upgrade other instance container types.
Contributes to issue CURA-844.
They might not exist any more because the relation of profiles to printers changed from 2.1 to 2.2 for some machines (notably the UM2+ variants). But then it'll just make it empty when loading.
Contributes to issue CURA-844.
Lots of things have changed in how this works. Sadly, I can't translate things like the material, from PLA to ultimaker2_plus_0.4mm_pla. Not without implementing the entire container registry in the plug-in anyway.
Contributes to issue CURA-844.
Machine instances have the exact same file structure as preferences, except that machine instances require a name field (was already correctly implemented), but preferences didn't require it. This now forbids preferences to have a name field, so that the distinction between the two can be made.
Contributes to issue CURA-844.
