This QML file was holding a copy of the currently connected printer, stored in connectingToPrinter. This copy got out of sync when you load a project file which had a different connected printer. Instead, ask the manager for the currently connected printer key every time you click the button.
Contributes to issue CURA-3839.
Except when we fill the instancecontainer via deserialising. Because then we want to retain the original version number.
Contributes to issue CURA-3427.
1.2 and lower didn't specify a version number. Assume that it was 1.2. We feed this through our translation function for form, mostly, because we know that the setting_version should be 0 then.
Contributes to issue CURA-3427.
One for the new setting_version. One for the misconception of version numbers being a major-minor version or something, because it's not stored that way.
Contributes to issue CURA-3427.
I'm not really awake today, am I? The functionality happened to still work because of how our real data is structured right now, but the tests still failed. Those are successful now.
Contributes to issue CURA-3427.
The density is already put in the 'properties' metadata entry. Don't need to put it in there doubly. Turns out that this density line was originally just superfluous.
Contributes to issue CURA-3427 or something.
The setting_version is translated from the version number. The setting_version number currently happens to be the same as the version number of XML but that won't always be the case so we introduce a translation-step as well.
Contributes to issue CURA-3427.
That density variable was never used. Hope this fixes some unaccounted-for bug.
Doesn't contribute to CURA-3427 but I'm listing it as if it does anyway.
Just a mistake that I saw because my IDE warned me about this. If a variant in Cura 2.3 has no general/name keyword, then it would break here. Now it doesn't break any more and gives a nonsensical name.
Contributes to issue CURA-3427.
We now have a (format) version and a setting version. Ideally we'd like major-minor version numbers in our profiles. However, introducing major-minor version numbers requires substantial changes to the version upgrade manager to compare version numbers, find a path towards the current version, or even keeping track of the current version. Therefore we just collapse the two version numbers into one: Multiply the major version number by a million and you'll never exceed it in the minor versioning. The only problem is that we now have to update the versioning for all of our three upgrade plug-ins, because they all need to know locally how to find the version number of their file types (because the upgrade manager has no knowledge of the file types) and they have no access to each other because a plug-in may be disabled.
Contributes to issue CURA-3427.
