Conflicts:
cura/PlatformPhysics.py -> Removed shapely on master, while QTimer import got updated to Qt6.
plugins/Toolbox -> Entire folder is deleted in master, but it was updated to Qt6 here. This can all be removed.
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.
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.
Python 3.9 now made the TreeBuilder.start() `attrs` parameter ([1])
mandatory on all implementations. Adapt the plugin accordingly.
[1] https://bugs.python.org/issue39495
One of the weirdest errors out there, and as far as I know we're the only ones suffering from it, due to having multiple packages of Python bindings created with Sip as well as having PyQt and different threads.
This alias shouldn't be written any more since the firmware misinterprets the setting value and errors when it's more than 100%.
Contributes to issue CURA-7724.
These settings are currently unused by cura, but passed into the PPA
output. Some considerations:
- material_ prepended to all. Even though they are not all
material specific. The consistency is more developer-friendly imho
- defaults taken from generic_pla
- type is float for all, consistent with what I found in this file
CURA-7041
The material groups are not filled any more in the material manager so this fails.
This might make updating metadata of material profiles slightly slower, but when testing this I noticed no difference.
The function becomes a lot simpler though. And it works again.
Contributes to issue CURA-6600.
Material profiles need to serialise subprofiles that belong to different printers as well. Some of these materials may not be loaded in the ContainerTree structure. To prevent having to load that as well, we're just not going to use the container tree any more. It turns out that the only reason it was using the container tree was to get the hardware_type metadata from the node in the tree. So just get that from the container itself and we're fine.
Contributes to issue CURA-6600.
