If the diameter doesn't match up, then the print fails. If the preference is not held up, then it chooses some random material and the user will understand what it chose.
Done during Turbo Testing and Tooling because a test was failing.
We only need the metadata, so far. Found with a test that got broken because I wasn't mocking out the entire container.
Done during Turbo Testing and Tooling.
We don't need to inherit from QObject if we expose the name elsewhere. This prevents having workarounds for C++ vs QML ownership, and also allows us to test this while mocking out CuraApplication.
Done during Turbo Testing and Tooling.
Remove the notion of a singular 'active' extruder from the code.
Visibility of intent profiles should consider all enabled extruders.
This fix makes sure that it doesn't matter in what order materials are
loaded, the available intent profiles will be the same.
CURA-6840
If a submaterial doesn't exist for the current variant node but it does exist for a different variant node, then it would not be found in the variant-specific materials and then would be looked up in the printer-specific materials. It then depends on the order in which findInstanceContainersMetadata returns things for whether the actual printer-specific material is selected or a different variant-specific material is selected. No longer now, because the variant name is specified to be absent so it may not match on variant-specific profiles any more.
Maybe this even gives us a small performance gain when combining these dictionaries, since there are now like 80% fewer profiles in that query.
Contributes to issue CURA-6831.
Turns out that the material profiles deserialise the variant to the 'variant_name' metadata entry, not just 'variant'. This caused it to find no variant-specific material profiles at all anywhere. It would always fall back to the machine-specific names.
Contributes to issue CURA-6831.
It's not behaving as expected here. For instance, Ultimaker 3 wasn't specifying has_machine_materials and thus only the base materials would get loaded, but clearly the Ultimaker 3 has materials specialised for it.
Whether or not a printer has materials specialised for it is now determined by whether the specialisations exist in the material files. So we don't need the metadata entry any more. It seemed to have not been in use anyway, except by one printer which specified that has_machine_materials is true. I've now made it behave as if it's always true.
Contributes to issue CURA-6831.
It's a quality container, not a material container. This was a copy-paste mistake.
Also added that this may be a global quality container, not always a per-extruder quality container.
Found during testing & tooling.
Previously it would use the material type from the material, but since
the material from the node can be different to that of the quality, we need
to use the one from quality instead (This is due to the fallback system)
CURA-6807
We just track it via the preference value itself rather than duplicating that in any other data structure. It's simple enough.
Contributes to issue CURA-6776.
