CURA-4084
When MachineManager gets created, it will find and set the current
active machine. This requires the ContainerRegistry to be initialized
first.
CURA-4084
Stack error checks are scheduled with a delay, and when a container is
changed (e.g. Quality), the auto-slice may get triggered before the
error check is done. Because the error check result is cached, the
auto-slicing will use the previous result instead of new. So, the
auto-slicing should be triggered when a stack validation is finished
instead of when a stack/setting gets changed.
CURA-4069
support_bottom_extruder_nr and support_roof_extruder_nr are the support
interface extruder numbers, so checking those two is enough and there is
no need to check the interface extruder number.
CURA-4069
getUsedExtruderStacks() doesn't take into account some new limit to
extruder features, The BuildVolume uses it to determine disallowed
areas, and this makes it give incorrect results.
If a PrinterOutputDevice is able to connect quickly to a machine, then
by the time the MachineManager is created and connects to the signal,
it will be too late, and it might miss that there is already connected
devices.
# Conflicts:
# plugins/USBPrinting/USBPrinterOutputDeviceManager.py
When this is imported during the __init__, it'll long have been imported elsewhere and won't need to import it again but still guarantees that it is actually imported if no other module does it first.
Contributes to issue CURA-4024.
When the setting is equal to the default the setting_version won't get written to the preferences file. In that case the version upgrade system assumes that the setting_version was 0 or 1 and upgrades it.
This makes sure that the setting is never equal to the default so that it always gets written.
Found while working on CURA-4024.
Recently we changed the empty containers such that there is only one empty container instance and it doesn't have the proper type any more. Instead we have properties on the stack that allows us to find the container with the proper type. It's faster and easier to use.
We've had a few bugs about this so I decided to update all of them to remove those for the future, except the ones in plugins/MachineSettingsAction/MachineSettingsAction.py because we have a pending pull request that fixes those. Fixing them would give merge conflicts for fieldOfView.
It doesn't really belong to CURA-4024 but I'm sticking it under that nomer anyway to get it reviewed.
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
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.
The approximate diameter needs to be in a static field because the list model filters on that field. The filter function is not clever enough to be able to filter on values being in some kind of range or rounded, so instead the decision was made that the rounded value needs to be set in a separate field so that the static filter can filter on it.
Contributes to issue CURA-2822.
It doesn't give a problem right now since we're only iterating over lists of length 1 here, but in the future this could cause weird bugs.
Contributes to issue CURA-2822.
Properties is a dictionary inside the metadata dictionary. If you change one of the properties, it'll check afterwards if the dictionary is different from what it was before, but since the dictionary is passed by reference all the time, it'll think that the dictionary didn't change: The reference is still the same, so the thing it checks against is updated along.
This solution is a bit ugly but it does notice when the metadata changed inside the properties and then emits a change signal.
Contributes to issue CURA-2822.
