So that they are also mapped from the global qualities to the flsun_sr-specific ones. This way they will be able to still be used in the newer Cura versions.
CURA-8510
Since the setting version 18 is used in the arachne beta build, we decided to make the the setting version to 19 in the normal releases, so that we make sure that projects made in arachne beta won't use any version upgrade scripts if a user attempts to open them in 4.12.
CURA-8510
We want to keep it this way so people can still make plugins work for older versions of Cura, like 3.6, where the 'api' field with just a single major version, instead of the 'supported_sdk_versions', which can be either a version-string like '7.6.0' or a list of version strings.
We've seen from experience that people do end up with broken files, due to user-modifications and whatnot. Corrupting it further won't make things better for the user.
Contributes to issue CURA-8212.
If the user account scope is outdated, delete it when upgrading from 4.8 to 4.9. This means that
the user will have to log in again, to make sure they get the correct account scope.
CURA-8093
If the 4.8 is started from a clean install and no category gets expanded in the settings panel,
then the "categories_expanded" key will not exist in the [cura] preferences in cura.cfg.
As a result, when the 4.9 gets started in this specific case, the version upgrade 48 to 49 will
produce a crash and will be considered as "failed", which will then lead to cura requesting from
the user to go from the entire onboarding flow instead of landing on the "What's new" pages (even
though everything else has been properly updated).
This commit fixes that by checking whether the "categories_expanded" key exists in the cura.cfg.
The Cura 4.9 release will have expanded functionality. If you have a plug-in that uses this functionality, marking it as using SDK 7.5.0 will notify older Cura releases that they can't use that plug-in.
The DisplayProgressOnLCD script was changed and the "time_remaining" was split into two settings:
the "time_remaining" and the "time_remaining_method". If the "time_remaining" was enabled, the
"time_remaining_method" should be set to "m117".
The VersionUpgrader48to49 was changing the "time_remaining" to "m117" instead of changing the
"time_remaining_method", which was leading to the "time_remaining" having a wrong value and not
being interpreted as a boolean.
This commit fixes that by setting the "time_remaining_method" into "m117" when the "time_remaining"
was True.
CURA-8110
It is known that will cause some user scripts to default behaviour.
But this is accepted behaviour, and the benefits of not upgrading
the Cura Application version outweigh this.
We're changing the unit of one of our settings, so we need to implement a version upgrade to change that for our users in case they changed this setting themselves.
Contributes to issue CURA-7118.
Since the metadata/setting_version field was not written in project files from the 3MF writer,
the preferences were never really updated, because their preferences version was marked as 6000000
(basically omitting the setting_version). Now, if any project file is found without a metadata
setting_version tag, it will default to preference version 6000000 and thus it will start calling
the updatedPreferences() functions starting from VersionUpgrade34to35, properly updating the
preferences and adding the metadata/setting_version field in the preferences.cfg of the project
file.
CURA-6711
It was decided that functionality present in existing plugins is
sufficient. No need to replicate it in our own codebase and
take on the burden of maintenance
CURA-5479
