We don't want to use it outside of the mapping. This mapping should be transparent.
We are still using it from our tests though but that's fine. Tests are allowed to touch private fields.
Contributes to issue CURA-6793.
This is just something I encountered. Could be that some profiles got corrupted. In my case, I had a bug in Uranium that I fixed later.
Contributes to issue CURA-6793.
This reverts commit fe8b7a48e6c4e7d4dc05d21f417a9968bef73cb3.
This commit caused Cura to crash when creating a custom quality profile.
Contributes to issue CURA-6883.
Also fix unnecessary emitting of switching extruder tabs.
This should improve performance a lot. I tested a lot of things and am convinced that it didn't break anything. But the automated GUI tests and QA team should be the final arbiters of that...
Contributes to issue CURA-6793.
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.
