Age | Commit message (Collapse) | Author |
|
In preparation for release of the 4.8.
CURA-7795
|
|
CURA-7641
|
|
The code was moved to uranium, so no need to test them in a plugin.
In some cases they were also testing a specific implementation artifact and not
actual expected behavior.
CURA-7388
|
|
They can still be overridden, but in the current situation they were
all the same...
|
|
CURA-7383
|
|
We've added new things to our API. This allows plug-in developers to use them.
Contributes to issue CURA-7205.
|
|
CURA-6858
|
|
|
|
CURA-6019
|
|
All plug-ins now have to re-check whether they are still compatible with the current version of Cura.
Contributes to issue CURA-6019.
|
|
These have to be strings because the configparser getter can only return strings.
Contributes to issue CURA-5936.
|
|
Hopefully we'll take this typing along when we next copy-paste the stuffs.
Contributes to issue CURA-5936.
|
|
I just looked for lines with interpolation = None because I was looking for another possible bug, but fixing this in the meanwhile too.
|
|
|
|
If we choose to rename the resource folders, then this plug-in should still look in the old resource folders. So hard-code these resource folders in the state that they were in at version 2.5 so that we can freely change them in a modern version.
|
|
CURA-5627
|
|
Otherwise the encoding is interpreted differently on Windows and Mac.
|
|
since they never get updated.
|
|
|
|
|
|
CURA-4188
The newly created extruder stacks don't have user containers, so the
user changes cannot be saved. This fix makes sure that in the upgrade,
user containers will be created.
|
|
CURA-4188
|
|
CURA-4188
|
|
CURA-4188
|
|
CURA-4188
Custom FDM printers in 2.5 don't have multi-extrusion support but they
do since 2.6. Upgrading from 2.5 to 2.6 will not create the missing
extruder stacks for the old custom FDM printers, which causes a crash.
This fix makes sure that all custom FDM printers will have 8 extruder
stacks during the upgrade so that Cura can still start normally and
those printers will still be usable.
|
|
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
|
|
CURA-3975
|
|
CURA-3975
- Preferences version is not set correctly
- The upgrade script should use a standalone version string because the
CuraApplication.SettingVersion can change
|
|
To be consistent with the rest of the plug-ins and with the material files.
Contributes to issue CURA-3857.
|
|
CURA-3712
|
|
CURA-3712
|
|
CURA-3712 & Cura-3856
|
|
CURA-3856 & CURA-3712
|
|
CURA-3837
|
|
CURA-3756
|
|
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.
|
|
Included a bit of a more difficult case.
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.
|
|
This was sort of hidden because we've always incremented the normal version number up until now.
Contributes to issue CURA-3427.
|
|
The normal version number is multiplied by a million. Currently these tests fail, so nice to have them.
Contributes to issue CURA-3427.
|
|
Oops.
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.
|
|
Contributes to issue CURA-3427.
|
|
The setting no longer exists. This removes it from all instance containers and preference files.
Contributes to issue CURA-3427.
|
|
Oops.
The test passes again now.
Contributes to issue CURA-3427.
|
|
Forgot that, sorry.
Contributes to issue CURA-3427.
|
|
The upgrade now upgrades profiles from the 2.5 format to 2.6, since we delayed the update for the 2.5 release.
Contributes to issue CURA-3427.
|