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.
Things to note:
* Since there is no VersionUpgrader from 4.8 to 4.9, this versionUpgrader attempts to upgrade
files made in 4.8. This means that it touches files with setting_version = 16.
* The upgrade of the setting_version to 18 is currently commented out because we are not entirely
sure that 18 will be the setting_version in 5.0.
* This versionUpgrader removes the following three settings that were removed in libArachne
* "Compensate Wall Overlaps"
* "Compensate Outer Wall Overlaps"
* "Compensate Inner Wall Overlaps"
* The VersionUpgrader also disabled Fuzzy Skin from any profiles that may have it enabled, as fuzzy
skin currently doesn't work in libArachne.
* The printer definitions have NOT been updated to the new setting_version to avoid having to deal
with an enormous merge conflict in case the setting_version of 5.0 is something other than 18.
* Since the VersionUpgrader does not alter the setting_version, it will run every time Cura starts.
In short, this versionUpgrader runs and removes the deleted settings but it does not really change
the setting_version of any files.
Contributes to CURA-7683 and CURA-7656
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
These two version upgraders do the same operation. Their code is copied. Instead, we can just let one version upgrader upgrade both versions of the files.
Contributes to issue CURA-7413.
Previously, the ironing_inset was changed in the profiles to reflect
the changes made in the CuraEngine. This inset though was not taking
into account the ironing_pattern (in the CuraEngine, the inset is
compensated differently depending on the pattern).
This commit fixes that in the version upgrader and the printer
definitions in order to maintain the same behavior for the old
profiles.
CURA-7318
The slicer has been adjusted to give this setting a more logical function: It should be an inset of the outer edge of ironing as it appears in layer view where the lines are made thinner according to their flow.
As a result all of the slices with ironing have changed. This adjusts the setting value so that the actual slice output will not change, just the appearance of the setting.
Contributes to issue CURA-7318.
