Save some settings Cura doesn't use, but other consumers of the file might in the metadata during deserilization, so they can be properly re-serialized whenever exported.
part of CURA-9432
We don't want to create actual settings for all of these. Just store them in the profile metadata and restore them.
Serialising and deserialising these is a bit more work than what I could do now in 5 minutes so we'll have to do that a bit later, but at least for now we have the complete list.
Contributes to issue CURA-9432.
Add function to fetch package_id using only information from XmlMaterialProfile material container.
The only piece of information associating the material container and the package together is the file_name. To find the package that owns a material we have to search each of the material package paths.
It would be great to find a cleaner solution (preferable one that doesn't require invalidating the cached containers).
CURA-8610
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
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.
