CURA-3975
This is a temporary fix to make materials work with 2.7 version upgrade
because of the setting_version change from 1 to 2. This MUST be fixed
after we have decided on how to determine the versions of an
XMLMaterialProfile.
CURA-3975
- Set Preferences setting_version in CuraApplication so Preferences can
get upgraded correctly
- Fix upgrade script for 2.5 to 2.6
- Fix upgrade script for 2.6 to 2.7 which relies on the upgrade of 2.5
to 2.6
If the quality profile was 'empty', then the container type wasn't properly set, so you can't find any quality profile. This gets the quality profile from the stacks, so you will find the empty profile (which has the wrong type but at least you can try to request metadata from it).
CURA-3975
- Preferences version is not set correctly
- The upgrade script should use a standalone version string because the
CuraApplication.SettingVersion can change
CURA-3975
When the ContainerRegister loads all container files, it decides which
actual class to use based on the registered MIME type of that file.
Because Cura registers the GlobalStack and ExtruderStack files as the
generic Uranium MIME type, the register loads them as Uranium
ContainerStacks. This commit solves this problem.
CURA-3975
GlobalStack has metadata type "machine", which is different from what is
registered in the VersionUpgradeManager "machine_stack". This commit
makes sure that Cura can find the correct upgrade route for the
GlobalStack files.
CURA-3975
The upgrade for machine and extruder stacks and the preferences files
don't work because the current version registering doesn't take into
account the 1000000 multiplier and the settings_version.
CURA-3975
Rename quality profiles with name "Not Supported" to have actual quality
names. Note that the "Not Supported" only ones are renamed to "Fast_Print".
Firstly, all the resolveOrValue calls are identity functions now so they can be phased out.
Secondly, all the max(extruderValues(...)) should be done by the resolve property rather than the value property. The resolve property already makes sure that the prime tower is evenly thick for every extruder, so it doesn't need to ensure this in the value function as well.
Contributes to issue CURA-3521.
This reverts commit 319559740dd8c8c2f9ffad637bee43cef9345073.
This was already fixed (line 734 inveted it). This code breaks it when there is no extruder
