The material is added multiple times to the variant nodes, and overwriting it with the eventual right one was going wrong.
This does not solve it entirely (because the less specific one still ends up selected _initially_ because it gets added first, and the order can't be guaranteed.
part of CURA-6863
It's not an InstanceContainer but a DefinitionContainer.
Also, when checking with the ID, it'll short circuit to the dictionary look up by ID. Then it's faster to directly check without specifying what type of container it is to prevent another nested function call.
Contributes to issue CURA-6793.
The findContainerStacks() will list all container stacks and lazily load them. However this lazy loading is done on the thread that's calling it. The lazy loading will create GlobalStack objects, which are QObjects. The QML code then can't access those QObjects because they are created on different threads. So now instead we'll do the find query on the main thread but all the rest on the background thread.
Contributes to issue CURA-6973.
Should be completely transparent. It'll fail the unit tests though because it now pretends that all printers have machine nodes.
Contributes to issue CURA-6793.
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.
